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PREFACE 

It is generally believed that the next generation of computers will involve 
massively parallel architectures. This thesis studies one of the proposed 
paradigms for exploiting parallelism, namely the actor model of concurrent 
computation. It is our contention that the actor model provides a general 
framework in which computation in distributed parallel systems can be 
exploited. The scope of this thesis is limited to theoretical aspects of the 
model as opposed to any implementation or application issues. 

Many observers have noted the computational power that is likely to 
become available with the advent of a new generation of computers. This 
work makes a small contribution in the direction of realizing technology 
which seems just on the horizon. The possibilities that emerge from the 
availability of a massive increase in computational power are simply mind 
boggling. Unfortunately, humankind has generally lacked the foresight to 
use the resources that science has provided in a manner that would be com- 
patible with its long-term survival. Somehow we have to develop an ethic 
that values compassion rather than consumption, to acquire a reverence for 
life itself. Otherwise this work, among others, will be another small step in 
the global march towards self-destruction. 

The research reported in this thesis was carried out for the most part 
at M.I.T., where I have been working with the Message-Passing Semantics 
Group. The group is currently implementing the Apiary architecture for 
Open Systems, which is based on the actor model. Much of the develop- 
ment of the actor paradigm has been inspired by the work of Carl Hewitt 
whose encouragement and constructive criticism has been indispensable to 
the development of the ideas in this thesis. Carl Hewitt also read and 
commented on drafts of this thesis. 

This thesis has been influenced by other work in the area of concur- 
rency, most notably that of Robin Milner. Although we have shied away 
from using a A-calculus like notation for an actor calculus, the transition 
system we develop has a similar flavor. Our preference has been for using a 
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programming language notation for purposes of overall clarity in expressing 
simple programs. 

John Holland has provided both intellectual impetus and moral sup- 
port over the years; in particular, numerous useful discussions with John 
have led to a better perspective on ideas in the field. I am also indebted to 
William Rounds for numerous suggestions, among them to develop a simple 
actor language and to illustrate its flavor by treating a number of commonly 
understood examples. My first thorough exposure to object-oriented archi- 
tectures was in a course offered by Paul Scott. Conversations with Robin 
Milner, Vaughn Pratt, and Joe Stoy have provided critical feedback. Will 
dinger's thesis interested me in the area of actor semantics. Members 
of the Message-Passing Semantics Group at M.I.T. have created an atmo- 
sphere which made the work described here possible. In particular, Henry 
Lieberman, Carl Manning, Chunka Mui and Thomas Reinhardt provided 
helpful comments. 

The work described in here was made possible by generous funding from 
the System Development Foundation and by the support of the Artificial 
Intelligence Laboratory at M.I.T. 

Finally, the time during which the ideas in this thesis were developed 
was a rather intense time in the lives of my family. Nothing would have 
been possible without the patient cooperation of my wonderful wife Jennifer 
Cole. It must be added that it was only due to the high spirits maintained 
by our son Sachal through most of his short, difficult life that any work at 
all could have been done by me. 

Gul Agha 

Cambridge, Massachusetts 

March 1985. 
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Chapter 1 



Introduction 



The purpose of any language is to communicate; that of a programming 
language is to communicate to a computer actions it ought to perform. 
There are two different sorts of objectives one can .emphasize in the design 
of a programming language: efficiency in execution, and expressiveness. 
By "efficiency," we refer here only to the speed with which the actions 
implied in a program can be carried out by the computer. In a precise 
sense, the most efficient programming language would be one that literally 
told the computer what actions to carry out; in other words, a machine 
language. 1 Expressiveness refers to the ease with which an program can 
be understood and shown to behave correctly. A programming language is 
expressive to the extent that it can be used to specify reasonable behaviors 
in the simplest possible terms. 



x Of course, every kind of processor has its own machine language. Some of these lan- 
guages may be "inherently" more efficient than others. 
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A programming language that maximized efficiency would not necessar- 
ily lead to the specification of programs with the best performance. This is 
simply because the programmer may end up spending more time figuring 
out how to express rather than what to express. The best gains in per- 
formance are to be achieved by discovering less computationally complex 
methods of achieving the same result. 

By and large, the goal of introducing new programming languages has 
been to make it simpler to express more complex behavior. Historically, 
the class of actions computers were first expected to carry out was that of 
computing well-defined mathematical functions. However, such computa- 
tions are no longer the only tasks a modern computer performs. In fact, the 
storage of information, sorting and searching through such information, and 
even exploration of an imprecisely defined domain in real-time are emerg- 
ing as significant applications. For example, computerized databases, such 
as the records maintained by a state Motor Vehicle Bureau, and artificial 
intelligence applications, such as computerized vehicles pioneering the nav- 
igation of Martian surface, are common uses of the computer. This more 
general use of computer programs has, in and of itself, important conse- 
quences for the class of behaviors we are interested in expressing. 

Although newer programming languages have generally favored con- 
siderations of expressiveness over those of efficiency, the ability to solve 
complex problems by means of the computer has nevertheless increased. 
This remarkable trend has been achieved by creating faster and bigger pro- 
cessors. However, there is now good reason to believe that we may have 
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approached the point of diminishing returns in terms of the size and speed 
of the individual processor. Already, smaller processors would be far more 
cost-effective, if we could use large numbers of them cooperatively. In par- 
ticular, this implies being able to use them in parallel. 

This brings us to the central topic of consideration in this thesis; namely, 
the development of a suitable language for concurrency. By concurrency 
we mean the potentially parallel execution of desired actions. Actually, 
concurrency by itself is not the real issue; after all concurrency has been 
exploited for a long time in the software revolution caused by time-sharing. 
The key difference between the now classic problem of operating systems, 
and our desire to exploit concurrency, is that in the former there is little 
interaction between the various "jobs" or "processes" that are executed 
concurrently. Indeed, the correctness of an operating system is dependent 
on making sure that none of the numerous (user- defined) processes affect 
each other. 

Our problem is quite the reverse: we wish to have a number of processes 
work together in a meaningful manner. This doesn't really imply that there 
are no important lessons to be learned from operating system theory. For 
example, notice that we switched from talking about "processors" to talking 
in terms of "processes" . A processor is a physical machine while a process 
is an abstract computation. From operating systems, we know that we may 
improve over-all performance of a processor by executing several processes 
concurrently instead of sequentially. How the processors are utilized is an 
issue for the underlying network architecture supporting the language. Our 
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interest is in a model of concurrency that exploits concurrently executed 
processes without assuming anything about their concrete realization. The 
processes may be distributed over a network of processors which can be used 
in parallel; however, if our programming language did not support concur- 
rency, such a distributed architecture would not result in any improvement 
in performance over a single processor. 

Actually, we are not so much concerned with a particular programming 
language, but rather, with the meta-linguistic issues behind the constructs 
of a concurrent language. The operational semantics of a language defines 
an instruction set for computation on an abstract machine. (More precisely, 
in case of the actor model, a system of machines). We are interested in the 
characteristics of the underlying models of computation. Specifically, we 
will examine the issues of expressiveness and efficiency in the context of 
concurrent computation. 

There are some intrinsic reasons for a theory of concurrency as well. One 
of these is the relevance of concurrency to an understanding of intelligent 
systems and communities. In particular, natural systems that appear to 
learn or adapt are all intrinsically parallel, and in fact quite massively so: 
the brain of animals, ecological communities, social organizations whether 
these are of human or non-human animals, are all examples of distributed 
systems that exploit concurrency. In fact, the genetic algorithm which is 
the foundation for adaptation and natural selection is itself intrinsically 
parallel [Holland 75]. The success of these mechanisms is sufficient grounds 
to interest one in the study of the implications of concurrent processing. 
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The rest of this chapter gives an overview of the thesis. The next chap- 
ter reviews the general design decisions that must be made in any model 
of concurrent computation. In Chapter 3, we describe the behavior of an 
actor and define a simple actor language which is used to show some spe- 
cific examples of actors. In the following chapter, we then define several 
higher level constructs which make the actor language more expressive, and 
provide a mechanism for abstraction in actor systems. These constructs are 
definable in terms of the primitive actor constructs and are not considered 
as part of the actor formalism. Chapter 4 also defines an expressional lan- 
guage, and discusses different strategies for the evaluation of expressions. 

Chapter 5 defines an operational semantics for actors by specifying a 
transition relation on configurations of actor systems. The guarantee of 
mail delivery is formalized by defining a second transition system which 
expresses this property. We take the primitive constructs of an actor lan- 
guage and show how one can provide these an with operational definition. 

In chapter 6, we are concerned with issues raised in related models. 
There are some significant difficulties in exploiting concurrency: Distributed 
systems often exhibit pathological behavior such as divergence and dead- 
lock. The actor model addresses these problems at a variety of levels. 
Divergence can be a useful property because of the guarantee of delivery; 
deadlock in a strict sense does not exist in an actor system. Besides, the 
asynchronous, buffered nature of communication in actors provides mech- 
anisms to detect deadlock in a semantic sense of the term. Chapter 6 also 
explores the relation between some aspects of dataflow and actors; in par- 
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ticular, the similarity between replacement in actors and what has been 
claimed to be the "side-effect free" nature of computation in both systems. 

Chapter 7 tackles the issue of abstraction and compositionality in actor 
systems. In particular, we discuss the nature of open systems and relate it 
to the insufficiency of the history relation observed in [Brock and Acker- 
man 77]. The right level of abstraction would permit us to treat equivalent 
systems as semantically identical and yet differentiate between systems that 
are unequal. We discuss the nature of composition in actors and show how 
we can model composition based on message-passing. 

The final chapter summarizes some of the implications of the work in 
this thesis. The Appendix uses tools from Milner's work to define an ab- 
stract representation for actor systems in terms of what are called Asyn- 
chronous Communication Trees. This representation provides a suitable 
way of visualizing computations in actors. 

Contributions 

The specific contributions of this thesis are summarized below. This thesis 
provides: 

• A critical overview of the various proposed models of concurrency. 

• A simple outline of the actor model and the specification of minimal 
primitive constructs for actor languages. 

• A transition system for actor systems and a structured operational 
semantics for an actor language. 
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• A paradigm for addressing problems in distributed computing which 
is suitable for computation in open systems. 

• A model to support compositionality and abstraction from irrelevant 
detail. 



Chapter 2 

General Design Decisions 

Several radically different models of concurrent computation have been pro- 
posed. In this chapter, we will review the concepts underlying each of 
the proposed models. Our interest is in comparing and contrasting their 
primitives with a view towards determining their generality. Of particular 
concern to us is the relative ease with which massively parallel architec- 
tures can be exploited. The design decisions fundamental to any model of 
concurrent computation include: 

• the nature of the computing elements 

• global synchrony versus asynchronous elements 

• the mode of interaction between computing elements 

• degree of fairness 

• reconfigurability and extensibility 
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This list is by no means exhaustive but represents the aspects we think 
are the most significant. There are other issues, such as the linguistic issues 
in the specification of a language based on each of the models, but we will 
ignore such details in our present discussion. We discuss each of the design 
issues in the sections that follow. 

2.1 The Nature of Computing Elements 

The elements performing computations are, in an abstract denotational 
sense, some kind of a function. However, the domain and range of the 
functions defining the behavior of the elements is quite different in each 
of the models. Ignoring some significant details, we identify three distinct 
kinds of computational elements: 

1. Sequential Processes. 

2. Functions transforming data values. 

3. Actors. 

2.1.1 Sequential Processes 

The operational notion of a sequential process is that it performs a sequence 
of transformations on states, where a state is a map from locations to 
values such as integers. In addition, the transformations may depend on 
certain "inputs" and produce "outputs." It is this latter aspect which makes 
the denotational semantics of systems of sequential process more difficult; 
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in particular, explicit consideration of the possibility of deadlock (when a 
process is waiting for input that never arrives) is required [Brookes 83]. 
Sequential processes are themselves, predictably, sequential in nature, but 
can execute in parallel with each other. 

In a sense, sequential processes are inspired by algol-like procedures in 
sequential programming. Examples of systems based on the concept of se- 
quential processes include Concurrent Pascal [Brinch Hansen 77], Commu- 
nicating Sequential Processes [Hoare 77], and the Shared Variables model 
[Lynch and Fischer 81]. 

2.1.2 Functions Transforming Data Values 

A second kind of computational element is a function which acts directly 
on data, without the benefit, or burden, of a store.' Such functional models 
are derived from the A-calculus based languages such as Pure Lisp [Mc- 
Carthy 59]. Examples of concurrent systems using some variant of the 
functional model include dataflow [Agerwala and Arvind 82] and networks 
of parallel processes [Kahn and MacQueen 77]. In dataflow architectures, a 
stream of (data) values pass through functional agents [Weng 75]. The con- 
currency in the system is a result of being able to evaluate the arguments 
to the functions in parallel. 

Perhaps the simplest model of systems using functions is an indeter- 
minate applicative system where the call-by-value is used to evaluate the 
arguments and the result of the computation is a single value. Computa- 
tion in such systems fans in as arguments are evaluated and passed along. 
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Fig. 2.1 shows an example of concurrent evaluation in an indeterminate 
applicative system. 

The functional elements may take several parameters as inputs but, 
given the parameters, can output only a single value. The same value 
may, however, be sent to different computational elements. Unfortunately, 
functions are history insensitive [Backus 78]. This can be a problem when 
modeling the behavior of systems that can change their behavior over time. 
For example, consider the behavior of a turnstile with a counter which 
records the number of people passing through it. Each time the turnstile is 
turned, it reports a new number on the counter. Thus its behavior is not 
simply a function of a "turn" message but sensitive to the prior history of 
the computation. The turnstile problem is essentially equivalent to that of 
generating the list of all integers, producing them one at a time in response 
to each message received. 

This problem is dealt with in some functional systems by feedback, using 
cyclic structures, as shown in Fig. 2.2 adapted from [Henderson 80]. The, 
turnstile is represented as a function of two inputs, a "turn" message and 
an integer n. Its behavior is to produce the integer n + 1 in response. The 
links act as (first-in first-out) channels, buffering the next value transmitted 
until the function has been evaluated and accepts more input. (The same 
value is sent down all the links at a fork in the diagram.) 
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Figure 2.1: An indeterminate applicative program. The parameters of the 
function are evaluated concurrently. 



2.1.3 Actors 

Actors are computational agents which map each incoming communication 
to a 3-tuple consisting of: 

1. a finite set of communications sent to other actors; 

2. a new behavior (which will govern the response to the next commu- 
nication processed); and, 

3. a finite set of new actors created. 
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Figure 2.2: History sensitive behavior as evaluation of a function with feed- 
back. 



Several observations are in order here. Firstly, the behavior of an actor 
can be history sensitive. Secondly, there is no presumed sequentiality in 
the actions an actor performs since, mathematically, each of its actions is 
a function of the actor's behavior and the incoming communication. And 
finally, actor creation is part of the computational model and not apart 
from it. An early precursor to the development of actors is the concept of 
objects in SIMULA [Dahl, et al 70] which represented containment of data 
with the operations and procedures on such data in a single object. 

Actors are a more powerful computational agent than sequential pro- 
cesses or value- transforming functional systems. In other words, it is possi- 
ble to define a purely functional system as an actor system, and it is possible 
to specify arbitrary sequential processes by a suitable actor system, but it 
is not possible to represent an arbitrary actor system as a system of sequen- 
tial processes or as a system of value-transforming functions. To see how 
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actors can be used to represent sequential processes or functional programs 
is not difficult: both are special cases of the more general actor model. If 
the reader is not convinced of this, the machinery developed later in this 
thesis should make it clear. 

It is easy to see why the converse is true: actors may create other ac- 
tors; value-transforming functions, such as the ones used in dataflow can 
not create other functions and sequential processes, as in Communicating 
Sequential Processes, do not create other seqiicntial processes. 1 In the se- 
quential paradigm of computation, this fact would not be relevant because 
the same computation could be represented, mathematically, in a system 
without actor creation. But in the context of parallel systems, the degree 
to which a computation can be distributed over its lifetime is an important 
consideration. Creation of new actors gxiarantees the ability to abstractly 
increase the distributivity of the computation as it evolves. 

2.2 Global Synchrony and Asynchrony 

The concept of a unique global clock is not meaningful in the context of a 
distributed system of self-contained parallel agents. This intuition was first 
axiomatized in [Hewitt and Baker 77] and shown to be consistent with other 
laws of parallel processing in [Clinger 81]. The reasoning here is analogous 



1 Sequential processes may activate other sequential processes and multiple activations 
are permitted but the topology of the individual process is still static. The difference 
between activation and creation is significant in the extent of reconfigurability afforded 
by each. 
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to that in special relativity: information in each computational agent is 
localized within that agent and must be communicated before it is known 
to any other agent. As long as one assumes that there are limits as to how 
fast information may travel from one computational agent to another, the 
local states of one agent as recorded by another relative to its own local 
states will be different from the observations done the other way round. 

We may conclude that, for a distributed system, a unique (linear) global 
time is not definable. Instead, each computational agent has a local time 
which linearly orders the events as they occur at that agent, or alternately, 
orders the local states of that agent. These local orderings of events are 
related to each other by the activation ordering. The activation ordering 
represents the causal relationships between events happening at different 
agents. Thus the global ordering of events is a partial order in which events 
occurring at different computational agents are unordered unless they are 
connected, directly or indirectly, because of one or more causal links. 

This is not to imply that it is impossible to construct a distributed 
system whose behavior is such that the elements of the system can be ab- 
stractly construed as acting synchronously. An example of such a system is 
Cook's hardware modification machine [Cook 81]. The hardware modifica- 
tion machine is a mathematical abstraction useful for studying the problems 
of computational complexity in the context of parallelism. 

The problem of constructing a synchronously functioning system is es- 
sentially one of defining protocols to cope with the fundamental epistemo- 
logical limitation in a distributed system. To see how the elements of a 
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system can be construed to be synchronous, consider the example shown 
in Fig. 2.3. 




Figure 2.3: A synchronizing mechanism: A Global Master controls the ele- 
ments of the system. 

Assume one element, called the global master, controls when each of 
the elements in the system may continue; all elements perform some pre- 
determined number of actions, report to the global master and wait for 
another "go" message from the global master before proceeding. The global 
master knows how many elements there are in the system and waits for each 
of them to report before sending out the next "go" message. Conceptually, 
we can think of each of the elements acting synchronously and the system 
passing through execution cycles on a "global clock". We can ignore the 
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precise arrival order of messages to the global master, because in such a 
system the exact order may be irrelevant. 

The important point to be made is that any such global synchronization 
creates a bottleneck which can be extremely inefficient in the context of a 
distributed environment. Every process must wait for the slowest process 
to complete its cycle, regardless of whether there is any logical dependence 
of a process on the results of another. Furthermore, it is not altogether 
obvious that such global synchrony makes it any easier to write programs 
in general. Although systems designed to act synchronously may be useful 
in some particular applications, we will deal with the general asynchronous 
distributed environment; the behavior of the synchronous system can al- 
ways be derived as a special case. (See, for example, the discussion in 
chapter 4 of mechanisms involving an effectively prioritized exchange of 
communications between two actors.) 

2.3 Interaction Between Agents 

How the elements of a concurrent system affect each other is one of the most 
salient features of any model of concurrent computation. The proposed 
modes of interaction between the computational elements of a system can 
be divided into two different classes: 

1. variables common to different agents; and, 

2. communication between independent agents. 
We take up these two modes of interaction in turn. 
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2.3.1 Shared Variables 

The basic idea behind the shared variables approach is that the various 
processes can read and write to variables common to more than one process. 
When one process reads a variable which has been changed by another, its 
subsequent behavior is modified. This sort of common variables approach 
is taken in [Lynch and Fischer 81]. 

The shared variables approach does not provide any mechanism for 
abstraction and information hiding. For instance, there must be pre- 
determined protocols so that one process can determine if another has 
written the results it needs into the relevant variables. Perhaps, even more 
critical is the fact that this approach does not provide any mechanism for 
protecting data against arbitrary and improper operations. An important 
software principle is to combine the procedural and declarative information 
into well-defined objects so that access to data is controlled and modularity 
is promoted in the system. This sort of absolute containment of information 
is also an important tool for synchronizing access to scarce resources and 
proving freedom from deadlock. In a shared variables model, the program- 
mer has the burden of specifying the relevant details to achieve meaningful 
interaction. 

2.3.2 Communication 

Several models of concurrent computation use communication between in- 
dependent computational agents. Communication provides a mechanism 
by which each agent retains the integrity of information within it. There 
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are two possible assumptions about the nature of communication between 
independent computational elements; communication can be considered to 
be either: 

• Synchronous, where the sender and the receiver of a communication 
are both ready to communicate; or, 

• Asynchronous, where the receiver does not have to be ready to accept 
a communication when the sender sends it. 

Hoare's Communicating Sequential Processes and Milner's Calculus of 
Communicating Systems assume synchronous communication while the ac- 
tor model [Hewitt 77] and dataflow architectures [Ackerman 84] do not. 

Let's examine each assumption and its implications. A concurrent com- 
putational environment is meaningful only in the context of a conceptually 
distributed system. Intuitively, there can be no action at a distance. This 
implies that before a sender can know that the receiver is "free" to ac- 
cept a communication, it must send a communication to the receiver, and 
vice-versa. Thus one may conclude that any model of synchronous commu- 
nication is built-on asynchronous communication. 

However, the fact that synchronous communication must be defined 
in terms of asynchronous communication does not necessarily imply that 
asynchronous communication is itself the right level of abstraction for pro- 
gramming. In particular, an argument could be made that synchronous 
communication should be provided in any programming language for con- 
current computation if it provides a means of writing programs without 
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being concerned with detail which may be required in all computation. 
The question then becomes if synchrony in communication is helpful as a 
universal assumption for a programming language. We examine this issue 
below. 

2.3.3 The Need for Buffering 

Every communication is of some finite length and takes some finite time 
to transmit. During the time that one communication is being sent, some 
computational agent may try to send another communication to the agent 
receiving the first communication. Certainly, one would not want to inter- 
leave the arbitrary bits of one communication with those of another! In 
some sense, we wish to preserve the atomicity of the communications sent. 
A solution to this problem is to provide a "secretary" to each agent which 
in effect tells all other processes that the agent is "busy." 2 Essentially, the 
underlying system could provide such a "secretary" in an implementation of 
a model assuming synchronous communication, as in a telephone network. 
There is another problem in assuming synchronous communication. 
Suppose the sender is transmitting information faster than the receiver 
can accept it. For example, as this thesis is typed in on a terminal, the 
speed of the typist may at times exceed the rate at which the computer is 
accepting the characters. To get around this problem, one could require 
that the typist type only as fast as the editing process can accept the char- 
acters. This solution is obviously untenable as it amounts to typing one 



'This could be done for instance by simply not responding to an incoming communication. 
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character at a time and waiting for a response (in fact, the argument would 
continue to the level of electrons!). The other solution is to provide the 
system with the capability to buffer the segments of a communication. 

Of course, if the underlying system is required to buffer segments of 
a communication, it can equally well be required to buffer different com- 
munications so that the sender does not have to be "busy waiting" for the 
receiver to accept a communication before it proceeds to do some other pro- 
cessing. Thus buffered asynchronous communication affords us efficiency in 
execution by pipelining the actions to be performed. Furthermore, syn- 
chronous communication can be defined in the framework of asynchronous 
comrminication. 3 The mechanism for doing so is simply "freezing" the 
sender until the receiver acknowledges the receipt of a communication [He- 
witt and Atkinson 77]. 

There is yet another significant advantage in buffered asynchronous 
communication. It may be important for a computational element to com- 
municate with itself; in particular, this is the case when an element defines 
a recursive computation. Communication with oneself is however impossi- 
ble if the receiver must be free when the sender sends a communication: 
this situation leads, immediately, to a deadlock because the sender will be 
"busy waiting" forever for itself to be free. The problem actually is worse: 



3 The notion of synchrony as simultaneity is physically unrealizable. The failure of si- 
multaneity at a distance occurs because whether two clocks are synchronous is itself 
dependent on the particular frame of reference in which the observations are carried 
out [Feynman, et al 1965]. We assume any notion of synchronous communication is a 
conceptual one. 
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no mutually recursive structure is possible because of the same reason. Mu- 
tual recursion, however, may not be so transparent from the code. There is 
no a priori problem with such recursive structures if the communications 
are buffered. 

Both the dataflow architecture for functional programming [Ackerman 82] 
and the apiary architecture for actor systems [Hewitt 80] provide the capa- 
bilities to buffer communications from asynchronous computing elements. 
However, it is not altogether obvious how the computational elements to 
provide for buffering communications can be defined in a functional lan- 
guage (as opposed to simply assumed). Such buffers are readily defined in 
actor languages. 

2.4 Nondeterminism and Fairness 

Nondeterminism arises quite inevitably in a distributed environment. Con- 
ceptually, concurrent computation is meaningful only in the context of a 
distributed environment. In any real network of computational agents, one 
can not predict precisely when a communication sent by one agent will ar- 
rive at another. This is particularly true when the network is dynamic and 
the underlying architecture is free to improve performance by reconfigur- 
ing the virtual computational elements. Therefore, a realistic model must 
assume that the arrival order of communications sent is both arbitrary 
and entirely unknown. In particular, the use of the arbiter as the hard- 
ware element for serialization implies that the arrival order is physically 



CHAPTER 2. GENERAL DESIGN DECISIONS 23 

indeterminate. 

2.4.1 The Guarantee of Delivery 

Given that a communication may be delayed for an arbitrarily long pe- 
riod of time, the question arises whether it is reasonable to assume that a 
communication sent is always delivered. In a purely physical context, the 
finiteness of the universe suggests that a communication sent ought to be 
delivered. However, the issue is whether buffering means that the guarantee 
of delivery of communications is impossible. There are, realistically, no un- 
bounded buffers in the physically realizable universe. This is similar to the 
fact that there are no unbounded stacks in the universe, and certainly not 
in our processors, and yet we parse recursive control structures in algolic 
languages as though there were an infinite stack. The alternate to assuming 
unbounded space is that we have to assume some specific finite limit; but 
each finite limit leads to a different behavior. There is, however, no general 
limit on buffers: the size of any real buffer will be specific to any particular 
implementation and its limitations. The point of building a semantic model 
is to abstract away from such details inherent in any implementation. 

The guarantee of delivery of communications is, by and large, a property 
of well- engineered systems that should be modeled because it has significant 
consequences. If a system did not eventually deliver a communication it 
was buffering, it would have to buffer the communication indefinitely. The 
cost of such storage is obviously undesirable. The guarantee of delivery 
does not assume that every communication is "meaningfully" processed. 
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For example, in the actor model, the processing of communications is de- 
pendent on the behavior of individual actors, and there may be classes of 
actors which ignore all communications or indefinitely buffer some com- 
munications. In particular, the guarantee of delivery provides one with 
mechanisms to reason about concurrent programs so that results analogous 
to those established by reasoning about the total correctness in sequential 
programs can be derived; in some cases, the guarantee helps prove termi- 
nation properties. 

2.4.2 Fairness and the Mail System 

Not all algorithms for delivering communications result in a mail system 
that guarantees delivery. For instance, a mail system that always delivered 
a "shorter" communication in its buffer may not deliver all communica- 
tions. Consider an agent, in such a system, which sent itself a "short" 
communication in response to a "short" communication. If a "long" and 
a "short" communication are concurrently sent to this actor, it may never 
receive the "long" communication. 

The guarantee of delivery is one form of what is called fairness. There 
are many other forms of fairness, such as fairness over arbitrary predicates, 
or extreme fairness [Pnueli 83] where probabilistic considerations are used. 
The guarantee of delivery of communications is perhaps the weakest form 
of fairness one can define (although it is not clear to me what sort of formal 
framework one would define to establish this rigorously). The question 
arises if one should assume a stronger form of fairness; for example, that 
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the communications sent are received in an probabilistically random order 
regardless of any property they have. 

Consider a system that chooses to deliver up to three "short" commu- 
nications for every "long" communication it delivers (if the shorter com- 
munications are found). Such a system would still satisfy the requirement 
of guaranteeing delivery of communications, but would not satisfy some 
stronger fairness requirements, for example, the requirement that all com- 
munications sent have an equal probability of being the next to be delivered. 
On the other hand, it may be very reasonable to have such an underlying 
mail system for some applications. We prefer to accept the guarantee of 
delivery of communications but not any form of fairness stronger than this 
guarantee. We will study the implications and Tisefulness of the guarantee 
later in this thesis. 

Of course, given the lack of a unique order of events in a distributed 
system, what the definitions of stronger forms of fairness really mean is 
not altogether obvious. Our initial cognizance in such cases can sometimes 
be misleading because our intuitions are better developed for sequential 
processes whose behavior is qualitatively different. In particular, the mail 
system is itself distributed and the delivery of communications, even ac- 
cording to a given observer, may overlap in time. 
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2.5 Reconfigurability and Extensibility 

The patterns of communication possible in any system of processes defines 
a topology on those processes. Each process (or computational agent) may, 
at any given point in its local time, communicate with some set of pro- 
cesses. As the computation proceeds, a process may either communicate 
only with the same processes it could communicate with at the beginning 
of the computation, or it may evolve to communicate with other processes 
that it could not communicate with before. In the former case, the inter- 
connection topology is said to be static; and in the latter, it is dynamic. 

Any system of processes is somewhat easier to analyze if its intercon- 
nection topology is static: the graph representing the connections between 
the processes is constant and hence relatively more information about the 
system is available at compile-time. Perhaps because of this structural 
simplicity in the analysis of static topologies, many models of concurrency 
assume that a process can communicate with only the same processes over 
its life-time. A static topology, however, has severe limitations in represent- 
ing the behavior of real systems. We illustrate these limitations by means 
of the following example. 

2.5.1 A Resource Manager 

Consider the case of a resource-manager for two printing devices. We 
may assume for our present purposes that the two devices are identical in 
their behavior and therefore interchangeable. One would like this resource- 
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manager to 

1. Send the print requests to the first available printing device. 

2. When a print request has been processed, to send a receipt to the user 
requesting the printing. 

These requirements imply that the resource-manager be able to commu- 
nicate with a different device each time. Thus a system where the commu- 
nication links were static and communications were sent down these links, 
without the resource-manager being able to choose which link ought to be 
used, would either send a communication to both the devices or to nei- 
ther. This is the situation in a dataflow graph shown in Fig. 2.4. However, 
resource-manager should be able to choose where it wants to send a com- 
munication (depending on which device is free), suggesting that the edges 
represent only potential communication channels and not actual ones. The 
true links would be dynamically determined. 

Suppose a system allowed the resource-manager to decide which of the 
two printing devices it wanted to communicate, with but relied on syn- 
chronous communication. The use of resources would be inefficient if the 
resource-manager was "busy waiting" for one particular printing device 
while the other one was idle. To get around this problem, suppose we re- 
quired the resource-manager to keep a track of which device, if any, was 
idle and to attempt to communicate only with such a device. In this case, 
when a busy device becomes idle, it must inform the resource-manager that 
it is free. Once again, if the resource-manager is required to specify which 
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Figure 2.4: A static graph linking the resource-manager to two devices. 



particular device it will accept input from, and be "busy waiting" to do so, 
the problem persists as it can not predict which one would be free first. 

Requiring a receipt to the user introduces other complications. For 
one, the number of users will vary with time. This variation by itself 
creates the need for a dynamic graph on the processes [Brock 83]. For 
another, the maximum number of users need not be constant. In a system 
that might evolve to include more resources, the addition of the increased 
capacity should be graceful and not require the redefinition of the entire 
system. This implies that a solution using a fixed number of communication 
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channels is not very satisfactory in an open system which is constantly 
subject to growth [Hewitt and de Jong 82]. For instance, if we wanted 
to add a third printing device, we should not necessarily have to program 
another resource-manager , but rather should be able to define a resource- 
manager which can incorporate the presence of a new printing device when 
sent an appropriate message to that effect. 

A system that is not only reconfigurable btit extensible is powerful 
enough to handle these problems. Reconfigurability is the logical pre- 
requisite of extensibility in a system because the ability to gracefully extend 
a system is dependent on the ability to relate the extension to the elements 
of the system that are already in existence. An elegant solution to this prob- 
lem of resource management using an actor system can be found in [Hewitt, 
et al 84]. 

2.5.2 The Dynamic Allocation of Resources 

Extensibility has other important consequences. It allows a system to dy- 
namically allocate resources to a problem by generating computational 
agents in response to the magnitude of a computation required to solve 
a problem. The precise magnitude of the problem need not be known in 
advance: more agents can be created as the computation proceeds and the 
maximal amount of concurrency can be exploited. 

For example, consider a "balanced addition" problem, where the ad- 
dition has to be performed on a set of real numbers. If the numbers are 
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added sequentially, 

{...{{{ax + a 2 ) + o 3 ) + a 4 ) + ... + o n ) 

then there is a classic problem of "propagation of errors," discussed in 
[von Neumann 58]. The problem occurs because real numbers are imple- 
mented using floating-point registers. Computational errors, instead of 
being statistically averaged, become fixed as rounding errors move to more 
significant bits. It is preferable to add the numbers in pairs, 

(...(((o! + o 2 ) + (o s + a 4 )) + ((05 + o«) + (...))) + -. + (a„_i + a„)...) 

which results in the error being statistically reduced by the "law of large 
numbers." 

Addition in pairs is ideal for concurrent computation because it can be 
done using parallel computation in log-time, as opposed to linear time when 
done sequentially. Now if we had a program to carry out this addition in 
pairs, we may like the program to work even if we input a different number 
of real numbers each time. Thus we can not define a static network to 
deal with this problem [Emden and Filho 82]. Addition in pairs is easily 
accomplished in an actor system by creating other actors, called customers, 
and doing the evaluations concurrently. Such concurrency is the default in 
actor languages. 

Reconfigurability in actor systems is obtained using the mail system 
abstraction. Each actor has a mail address which may be freely commu- 
nicated to other actors, thus changing the interconnection network of the 
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system of actors as it evolves. We will discuss the specific mechanisms later 
in this thesis. 



Chapter 3 

Computation In Actor 
Systems 



In this chapter, we examine the structure of computation in the actor 
paradigm. The discussion here will be informal and intuitive, deferring 
consideration of the technical aspects to later chapters. The organization 
of this chapter is as follows. In first section, we explain actors and commu- 
nications. The second section outlines the constructs which suffice to define 
a minimal actor language. We give some examples of actor programs to 
illustrate the constructs using only structured "pseudo-code." In the final 
section, kernels of two simple actor languages are defined and a program 
example is expressed in each of these languages. The two languages, SAL 
and Act, are both minimal yet are sufficient for defining all possible actor 
systems. SAL follows an algol-like syntax while Act uses a Lisp-like syntax. 
In the next chapter, we will define some new linguistic constructs, but these 
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constructs will not be foundational; they can be defined using a minimal 
actor language. Such extensions to a minimal language demonstrate the 
power of the primitive actor constructs. 

3.1 Defining an Actor System 

Computation in a system of actors is in response to communications sent 
to the system. Comnmnications are contained in tasks. As computation 
proceeds, an actor system evolves to include new tasks and new actors that 
are created as a result of processing tasks already in the system. All tasks 
that have already been processed (and all actors that are no longer "useful," 
a notion we will define more precisely), may be removed ( i.e., garbage 
collected) from the system without affecting its subsequent behavior. 1 The 
configuration of an actor system is defined by the actors it contains as well 
as the set of unprocessed tasks. 

3.1.1 Tasks 

In somewhat simplified terms, we can say that the unprocessed tasks in a 
system of actors are the driving force behind computation in the system. 
We represent a task as a three tuple consisting of: 

1. a tag which distinguishes it from all other tasks in the system; 



1 We refer here to the semantic equivalence of the systems with and without "garbage." 
Of course, the performance of the system is a different matter. 
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2. a target which is the mail address to which the communication is to 
be delivered; and, 

3. a communication which contains information made available to the 
actor at the target, when that actor processes the given task. 

As a simplification, we will consider a communication to be a tuple of 
values. The values may be mail addresses of actors, integers, strings, or 
whatever, and we may impose a suitable type discipline on such values. 
There are other possible models here; perhaps the most exciting of such 
models, and the one iising the greatest uniformity of construction, is one 
in which the communications are themselves actors. 2 In such a model, 
communications may themselves be sent communications. For example, if 
we want a communication k± to print itself, we could send a communication 
ki to the communication fci which asked ki to print itself. Communications 
as actors also provide an effective and simple way to implement call-by- 
need using futures, where a future is a communication that can be sent a 
communication to evaluate itself. The semantic theory of actors is, however, 
considerably complicated by modelling communications as actors, and we 
therefore won't do so here. 3 



2 The behavior of an actor is to send communications to other actors it knows about (i.e., 
its acquaintances), which in turn do the same until the communications are received by 
pre-defined primitive actors such as numbers and primitive pre-defined operations (See 
Section 4.4.). In the more general universe of actors model, tasks themselves are actors 
which have three acquaintances, namely the three components of the tuple given above. 

3 For a discussion of the universe of actors model see §4.4. 
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The target must be a valid mail address. In other words, before an 
actor can send the target a communication, it must know that the target 
is a valid mail address [Hewitt and Baker 77] . There are three ways in 
which an actor a, upon accepting a communication k, can know of a target 
to which it can send a communication. These are: 

• the target was known to the actor a before it accepted the commu- 
nication k, 

• the target became known when a accepted the communication k be- 
cause it was contained in the communication k, or 

• the target is the mail address of a new actor created as a result of 
accepting the communication k. 

t 

A tag helps us to uniquely identify each task by distinguishing between 
tasks which may contain identical targets and communications. We will 
make use of the uniqueness of each tag when we define an operational 
semantics for actor systems. An important observation that should be 
made here is that any particular representation of the tags is somewhat 
arbitrary. The tags are specified because they are useful in keeping a track 
of tasks. However, the tasks themselves are existentially distinct entities. 

There are various ways of representing tags; one such representation 
is a string of nonnegative integers separated by "." (periods). Using this 
representation, if w is a tag for task t, then w.n, where n is some nonnegative 
integer, can be the tag for some task created as a result of processing t. 
In this way, if we start with a set of tags uniquely associated with the 
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tasks, we can guarantee that all tasks always have distinct tags (by using a 
restriction that the last number appended is distinct for each task created 
by the same actor in response to the same communication). Note that there 
may be only a finite number of tasks in any given system. 

3.1.2 The Behavior of an Actor 

As we discussed earlier, all computation in an actor system is the result 
of processing communications. This is somewhat similar to a data-driven 
system like dataflow, and in contrast to systems based on processes that 
either terminate or are perpetually "active." Actors arc said to accept a 
communication when they process a task containing that communication. 
An actor may process only those tasks whose target corresponds to its mail 
address. When an actor accepts a communication, it may create new actors 
or tasks; it must also compute a replacement behavior. 

For any given actor, the order of arrival of communications sent to that 
actor is a linear order. In particular, this implies that the mail system must 
provide suitable mechanisms for buffering and arbitration of incoming com- 
munications when such communications arrive at roughly the same time. 
The mail system places the communications sent to a given target on the 
mail queue corresponding to that target. For most purposes, it is appropri- 
ate to consider the mail queue as part of the mail system. However, when 
we wish to deal with issues related to the arrival order of communications, 
such as the guarantee of mail delivery 4 we have to consider the mail queue 



4 The presence of communication failures in a real system should not be considered a hin- 
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explicitly. 

An actor may be described by specifying: 

• its mail address, to which there corresponds a sufficiently large mail 
queue 5 ; and, 

• its behavior, which is a function of the communication accepted. 

Abstractly, we may picture an actor with a mail queue on which all 
communications are placed in the order in which they arrive and an actor 
machine 6 which points to a particular cell in the mail queue. The end of a 
communication on the mail queue can be indicated by some special symbol 
reserved for the purpose. 7 We represent this pictorially as in Fig. 3.1. 

When an actor machine X n accepts the nth communication in a mail 
queue, it will create a new actor machine, X n +i, which will carry out the 
replacement behavior of the actor. This new actor machine will point to 



drance for a theoretical investigation assuming a reliable mail system. See the discussion 
in Section 2.4. 

5 The mail queue will be considered large enough to hold all communications sent to a 
given actor. This implies that a mail queue is, in principle, unbounded, while only a 
finite fragment of it is used at any given point in time. This is quite similar to a read- 
only tape of a Turing Machine. However, the writing is done, indirectly, using the mail 
system. 

6 No assumption should be made about an actor machine being sequential, indeed, an 
actor machine, much like machines in the real world, may have components that function 
in parallel. 

7 Thus the variable length of a communication is not a problem. 
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Figure 3.1: An abstract representation of an actor. The actor machine 
contains information that determines the behavior of an actor. It accepts 
the current communication and can not process information from any other 

y 

communication. 



the cell in the mail queue in which the n+lit communication is (or will be) 
placed. This can be pictorially represented as in Fig. 3.2. 

The two actor machines X n and X n+i will not affect each others be- 
havior: X n processes only the nth communication. (Of course, if X n sends 
the actor itself a communication, X n+ i may be the actor machine which 
processes the same.) Specifically, each of the actor machines may create 
their own tasks and actors as defined by their respective behaviors. Before 
the machine X n creates X n+i , X n may of course have already created some 
actors and tasks; however, it is also the possible that X n may still be in 
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Figure 3.2: An abstract representation of transition. 



the process of creating some more tasks and actors even as X n+ i is doing 
the same. In any event, note that the machine X n will neither receive any 
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further communications nor will it specify any other replacement. 8 

If we define an event as the creation of a new actor or task, or the speci- 
fication of the replacement, then the order of events that are caused, at any 
actor, by the acceptance of communications is a partial order. The replace- 
ment machines at any mail address have a total order between them. This 
linear order is isomorphic to the arrival order of the corresponding com- 
munications which result in their replacement (as may be readily inferred 
from the Fig. 3.2). 

An event-based picture for computation in actors uses life-lines which 
are shown in Fig. 3.3. Each actor has an order of acceptance of communi- 
cations which is linear. The events in the life of an actor are recorded in the 
order in which they occur: the further down the line, the later in local time. 
Activations (causal ordering of events) are indicated by the lines connecting 
two different actors with the arrow on the line indicating causal direction. 
Finally, each lifeline is labeled by the pending communications, i.e., the 
communications that have been received but not processed. Clinger [81] 
used collections of life-lines to provide a fixed-point semantics for actors. 
The resulting pictures are called the actor event diagrams. 

A couple of general remarks about the implementation issues are in 
order here: 

Remark 1. The reader may wonder about the efficiency of constructing a 
new actor machine in response to each communication accepted. It should 



8 We will later model functions that require more input as a collection of these elemental 
actors. 



CHAPTER 3. COMPUTATION IN ACTOR SYSTEMS 41 

be emphasized that this is simply a conceptual assumption that frees us 
from the details of any particular implementation. Concurrency simply 
means potential parallelism. Some implementations may find it useful to 
generally delay constructing the replacement until the old machine can be 
cannibalized. However, delaying the construction of the replacement is not 
a universal requirement as would be the case in a sequential machine. Thus, 
if there are sufficient resources available, computation in an actor system 
can be speeded up by an order of magnitude, by simply proceeding with 
the next communication as soon as the ontological necessity of determining 
the replacement behavior has been satisfied. The advantages of this kind 
of pipelining can be illustrated by the following simple example: Consider 
a calculation which requires 0(n 2 ) sequential steps to carry out, where 
0(n) represents the size of input. Suppose further that computing the 
replacements takes only (n) steps. If we had a static architecture with 
0{m) processes, it would take 0(n 2 ) cycles per calculation. By pipelining, 
an actor-based architecture could carry out m calculations in the same 
time as a single calculation because it would initiate the next computation 
as soon as the replacement for the previous one had been computed — a 
process taking only 0(n) steps. 

Remark 2. It should also be pointed out that the structure of an ac- 
tor machine is extremely concurrent: when any particular segment of the 
computation required by the acceptance of a communication has been com- 
pleted, the resources used by the corresponding fragment of the "machine" 
are immediately available. It may be difficult, if one thinks in terms of 
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creates actors 



Figure 3.3: Actor event diagrams. Each vertical line represents the events 
occurring in the life of an actor. The arrows represent causal links. 



sequential processes, to conceive of the inherent parallelism in the actions 
of an actor. The structure of computation in a sequential process is lin- 
ear: typically, activations of procedures are stacked, each activation storing 
its current state. However, in an actor program, the absence of assign- 
ment commands permits the concurrent execution of the commands in a 
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specification of the behavior of an actor. We will discuss the specific mech- 
anisms for spawning concurrency, such as the use of customers to continue 
computations required for a transaction, later in this chapter. 

3.2 Programming With Actors 

In this section, we define the constructs necessary for the kernel of a min- 
imal actor language. We also give some simple examples of actor pro- 
grams. These examples illustrate, among other things, the versatility of 
message-passing as a general mechanism for implementing control struc- 
tures, procedure and data abstraction in the actor construct, and the use 
of mail addresses instead of pointer types in data structures. The feasibility 
of representing control structures as patterns of message-passing was first 
described in [Hewitt 77]. 

Despite its simplicity, the kernel of an actor language is extremely pow- 
erful: it captures several important features of computation in the actor 
paradigm; among them, the ability to distribute a computation between 
concurrent elements, the ability to spawn maximal concurrency allowed by 
the control structure, the unification of procedural and declarative infor- 
mation, data abstraction and absolute containment, and referential trans- 
parency of identifiers used in a program. 

An actor accepts a single communication as "input." Thus, if a com- 
putation is a function of communications from several different actors, it 
has to be defined using a system of actors. We will introduce linguistic 
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constructs to simplify expressing some multi-input functions in a trans- 
parent manner. All such constructs can be defined in terms of the actors 
definable in a minimal actor language, and we therefore confine our present 
discussion to the constructs necessary for a kernel language. 

3.2.1 The Basic Constructs 

To define the initial configuration of an actor system we need to create 
some actors and to send them some communications. However, we also 
promote modularity by specifying the actors that may communicate with 
the "outside," i.e., with actors not defined within the configuration. A 
program in an actor language consists of: 

• behavior definitions which simply associate a behavior schema with 
an identifier (without actually creating any actor). 9 

• new expressions which create actors. 

• send commands which are used to create tasks. 

• receptionist declaration which lists actors that may receive communi- 
cations from the outside. 

• external declaration which lists actors that are not part of the popu- 
lation defined by the program but to whom communications may be 



9 Such behavior schemas are not considered to be actors in the simple model we are 
currently tising. In another language, such definitions can be used to create actors that 
are "descriptions" of actor behaviors. The behavior of such description actors would be 
to create actors of the given description when sent an appropriate communication. 
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sent from within the configuration. 

We discuss the syntax and intended meaning for each of the expressions 
which can be used in a minimal language. For some simple expressions, we 
also show what a feasible syntax might be. 

Defining Behaviors 

Each time an actor accepts a communication, it computes a replacement 
behavior. Since each of the replacement behaviors will also have a replace- 
ment behavior, in order to specify the behavior of an actor, we need to 
specify a potentially infinite definition. Obviously one can not write an in- 
finite string to define each replacement. Fortunately, we have the principle 
of recursive (or inductive) definition so familiar from mathematics. Essen- 
tially, we parameterize each expressible behavior by some identifier which 
will be a free variable in the definition. Whenever a behavior is specified 
using the behavior definition, we must specify specific values for the iden- 
tifiers parameterizing the behavior definition. For example, the behavior 
of a bank-account depends on the balance in the account. We therefore 
specify the behavior of every account as a function of the balance. When- 
ever a particular account is created, or a replacement behavior specified, 
which uses the behavior definition of a bank-account, a specific value for 
the balance in the account must be given. 

There are also an infinite number of possible values for the incoming 
communication. Therefore, a behavior definition is expressed as a function 
of the incoming communication. 
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Two lists of identifiers are used in a behavior definition. The first list 
corresponds to parameters for which values must be specified when the actor 
is created. This list is called the acquaintance list. The second list of pa- 
rameters, called the communication list, gets its bindings from the incoming 
communication. When an actor is created, and it accepts a communication, 
it executes commands in the environment defined by the bindings of the 
identifiers. 

Creating Actors 

Actors are created using new expressions which return the mail address of 
a newly created actor. The mail address should be bound to an identifier or 
communicated; otherwise, it would not be useful to have created the actor. 
The syntax of new expressions would be something corresponding to the 
following : 

(new expression) ::= new (beh name) ( expr { , expr }* ) 

The (beh name) corresponds to an identifier bound to a behavior given 
by a declaration using a behavior definition. A new actor is created with 
the behavior implied by the behavior definition and its parameters are 
instantiated to the values of the expressions in the parenthesis. In actor 
jargon, we have defined the acquaintances of an actor. The value of the 
expression is the mail address of the actor created and it can be bound to 
an identifier called an actor name by a (let command). An actor name may 
be used as the target of any communication, including communications sent 
in the initial configuration. 
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Actors created concurrently by an actor may know each others mail 
addresses. This is a form of mutually recursive definition permissible in 
actors. However, all the newly created actor knows is the mail address of 
the other actor: It docs not have any other direct access to the internal 
structure of that actor. 

Creating Tasks 

A task is created by specifying a target and a communication. Communi- 
cations may be sent to actors that already existed, or to actors that have 
been newly created by the sender. The target is the mail address of the 
actor to which the communication is sent. The syntax of a command that 
would create tasks is something like the one given below: 

{send command) ::= send (communication) to (target) 

where a communication is a sequence of expressions (perhaps empty). The 
expressions may be identifiers, constants, or the appropriate functions of 
these. The expressions are evaluated and the corresponding values are sent 
in the communication. The target is an identifier bound to the mail address 
of an actor. 

Declaring Receptionists 

Although creating actors and tasks is sufficient to specify an actor system, 
simply doing so does not provide a mechanism for abstracting away the 
internal details of a system and concentrating on the behavior as it relates 
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to outside the actor system specified by the program. In order to simplify 
reasoning about the composition of independently defined and debugged 
systems and to permit greater modularity in a system, we allow the pro- 
grammer to specify the initial set of receptionists for any system. The 
receptionists are the only actors that are free to receive communications 
from outside the system. Since actor systems are dynamically evolving and 
open in nature, the set of receptionists may also be constantly changing. 
Whenever a communication containing a mail address is sent to an actor 
outside the system, the actor residing at that mail address can receive com- 
munications from the outside and therefore become a receptionist. The set 
of receptionists increases as the system evolves. 

If no receptionists are declared, the system can not initially receive 
communications from actors outside the system. However, the mail address 
of an actor may subsequently be delivered to an external actor, so that the 
actor system may evolve to include some receptionists. This illustrates the 
potentially dynamic nature of the set of receptionists. 

Declaring External Actors 

Communications may be sent to actors outside an actor system. Typically, 
an actor may get the mail address of another actor which is not in the 
system in a communication from the outside. It would then be able to send 
communications to this actor. However, even when an actor system is being 
defined, it may be intended that it be a part of a larger system composed 
of independently developed modules. Therefore, we allow the ability to 
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declare a sequence of identifiers as external. The compiler associates these 
identifiers with actors whose behavior is to buffer the communications they 
accept. Whenever a given actor system is composed with another in which 
the external actors are actually specified, the buffered mail can be forwarded 
to the mail address of the actual actor (which was hitherto unknown). We 
will show how the compositionality can be actually implemented in an open, 
evolving system using message-passing. 

There need be no external declaration in an program. In this case, no 
communication can initially be sent to mail addresses outside the actor 
system defined by the program. However, as the system receives commu- 
nications from the outside, the set of external actors will "grow." Notice 
that it is useless to have an actor system which has no receptionists and no 
external actors because such an autistic system will never affect the outside 
world! 

Commands 

The purpose of commands is to specify the actions to be carried out. We 
have already discussed most of the basic commands which would create new 
actors and new tasks. We also need a command to specify a replacement. 
The syntax of the become command in SAL is: 

become (expression) 

where the expression is bound to a mail address. The actor simply forwards 
all its mail to the actor at the specified mail address. If the expression is 
a new expression, then there is no need to assign a new mail address to 
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the created actor since that mail address would be equivalent to the mail 
address of the actor it is replacing. Thus the picture in Fig. 3.2 is concep- 
tually correct. If the expression is the mail address of an already existing 
actor then operationally the actor becomes a forwarding actor to the exist- 
ing actor. In this case, the picture in Fig. 3.2, although literally correct, 
does not express the equivalence of the two mail queues. Denotationally, 
the replacement behavior is the same as the behavior of the actor to which 
the communication is forwarded. This denotational equivalence would not 
be valid in a model which did not assume arrival order non-determinism 
and the guarantee of delivery. 

There is one other kind of command which is necessary: a conditional 
which determines which branch is taken. Conditional or branching com- 
mands are of the usual if-then or case form. It is also useful to allow let 
bindings so that identifiers may serve as a shorthand for expressions in a 
particular context. We have already shown the use of let bindings in the 
recording of the mail addresses of newly created actors. 

Default Behaviors 

Since all actors must specify a replacement behavior, we use the default 
that whenever there is no executable become command in the code of an 
actor in response to some communication, then we replace that actor with 
an identically behaving actor. Since the behavior of an actor is determined 
by a finite length script involving only conditional commands for control 
flow, it is can be thought of as a finite depth tree one of whose branches is 
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executed. The particular branch executed depends on the communication. 10 
Thus it is (easily) decidable if no replacement has been specified for a given 
acquaintance and communication list. 

3.2.2 Examples 

We define several examples of programs written using actors. These ex- 
amples illustrate the relative ease with which various data structures and 
control structures can be implemented in an actor language. Specifically, 
we will give the implementation of a stack as a "linked list" of actors. 
This simple example also illustrates how the acquaintance structure makes 
the need for pointer types superfluous in an actor language. Other data 
structures can be defined in a similar manner. 

The second example we present is that of the recursive factorial func- 
tion. This is a classic example used in (almost) any work on actors. An 
iterative control structure can also be easily defined [Hewitt 77]; we leave 
it as an exercise for the interested reader. The technique for an iterative 
factorial is similar to the standard accumulation of parameters in functional 
programming. The final example in this section is an implementation for 
an actor specified by an external declaration. This example should clarify 
the use of external declarations to bind actors that are in the population of 
some independent module. The independent module can be later composed 
with the module presently being specified. We will deal with some more 



10 The tree need not be finitely branching because the communications can be one of an 
arbitrary countable set. 
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complex examples in the next chapter. 

Example 3.2.1 A Stack. We implement a stack as a collection of actors 
with uniform behavior. These actors will represent total containment of 
data as well as the operations valid on such data. Assume that the linked 
list consists of a collection of nodes which store a value and know the mail 
address of the "next" actor in the link. The code for defining a stack element 
is given below. We skip all error handling code because such details will 
simply detract from the basic behavior being expressed. We assume that 
there is a pre-defined value NIL and use it as a bottom of the stack marker. 
Two kinds of operations may be requested of a stack- node: a push or a pop. 
In the first case, the new content to be pushed must be given, and in the 
second, the customer to which the value stored in the stack-node can be 
sent. 

a stack-node with acquaintances content and link 

if operation requested is a pop A content ^ NIL then 

become link 

send content to customer 
if operation requested is push then 

let P = new stack-node with current acquaintances 

{ become new stack-node with acquaintances new-content and P } 

The top of the stack is the only receptionist in the stack system and was 
the only actor of the stack system created externally. It is created with a 
NIL content which is assumed to be the bottom of the stack marker. Notice 
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that no mail address is ever communicated by any node to any external 
actor. Therefore no actor outside the configuration defined above can af- 
fect any of the actors inside the stack except by sending the receptionist 
a communication. When a pop operation is done, the actor on top of the 
stack simply becomes the next actor in the link. This means that all com- 
munications received by the top of the stack are now forwarded to the next 
element. 

For those concerned about implementation efficiency, notice that the 
underlying architecture can splice through any chain of forwarding actors 
since their mail address would no longer be known to any actor, and in due 
course, will not be the target of any tasks. The user is entirely free from 
considering the details of such optimizations. 

Example 3.2.2 A Recursive Factorial. We give this classic example 
of a recursive control structure to illustrate the use of customers in im- 
plementing continuations. The example is adapted from [Hewitt 77] which 
provided the original insight exploited here. In a sequential language, a re- 
cursive formula is implemented using a stack of activations. In particular, 
the use of a stack implies that a factorial can accept only one communica- 
tion from some other actor and is busy until it has computed the factorial 
of the given number. There is no mechanism in the sequential structure for 
distributing the work of computing the factorial or concurrently processing 
more than one request. 

Our implementation of the factorial actor relies on creating a customer 
which waits for the appropriate reply, in this case from the factorial itself, 
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so that the factorial is concurrently free to process the next communication. 
We assume that a communication to a factorial includes a mail address to 
which the value of the factorial is to be sent. The code for a recursive 
factorial is given below. Note that we use self as the mail address of the 
actor itself. This mail address will be instantiated when an actor is actually 
created using the behavior definition and serves as shorthand by eliminating 
the need for a parameter in the definition. 

Rec-Factorial with acquaintances self 

let communication have an integer n and a customer 
become new Rec-Factorial 
if n = 

then send [l] to customer 
else let c be a Rec-Customer created which will accept an integer k 
and send n*k to the customer 
{ send n — 1 , the mail address of c to self } 

In response to a communication with a non-zero integer, n, the actor 
with the above behavior will do the following : 

• Create an actor whose behavior will be to multiply the n with an 
integer it receives and send the reply to the mail address to which the 
factorial of n was to be sent. 

• Send itself the "request" to evaluate the factorial of n — 1 and send 
the value to the customer it created. 
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One can intuitively see why the factorial actor behaves correctly, and 
can use induction to prove that it does so. Provided the customer is sent the 
correct value of the factorial of n — 1, the customer will correctly evaluate 
the factorial of n. What's more, the evaluation of one factorial doesn't 
have to be completed before the next request is processed; i.e., the factorial 
actor can be a shared resource concurrently evaluating several requests. 
The behavior of the factorial actor in response to a single initial request is 
shown in Fig. 3.4. 

This particular function is not very complicated, with the consequence 
that the behavior of the customer is also quite simple. In general, the 
behavior of the customer can be arbitrarily complex. The actor originally 
receiving the request delegates most of the processing required by the re- 
quest to a large number of actors, each of whom is dynamically created. 
Furthermore, the number of such actors created is in direct proportion to 
the magnitude of the computation required. 

There is nothing inherently concurrent in the recursive algorithm to 
evaluate a factorial. Using the above algorithm, computation of a single 
factorial would not be any faster if it were done using a sequential language 
as opposed to an actor language. All we have achieved is a representation 
of the stack for recursion as a chain of customers. However, given a network 
of processors, an actor-based language could process a large number of re- 
quests much faster by simply distributing the actors it creates among these 
processors. The factorial actor itself would not be the bottleneck for such 
computations. (Of course, it would be useful to have fast communication 
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Figure 3.4: The computation in response to a request to evaluate the facto- 
rial of S. The \j) 's represent dynamically created customers (see text). 



links between the processors). 

In general, there are also more parallel algorithms for evaluating func- 
tions, and these algorithms can be exploited in an actor-based language. 
For example, a more parallel way of evaluating a factorial treats the prob- 
lem as that of multiplying the range of numbers from l...n. The problem is 
recursively subdivided into multiplying two subranges. Such an algorithm 
results in the possibility of computing a single factorial in log n parallel 



CHAPTER 3. COMPUTATION IN ACTOR SYSTEMS 57 

time. 

Example 3.2.3 External Actors. An actor program defines an initial 
configuration with its external actors defined by an (external declaration) . 
To promote composition of independently programmed modules, the exter- 
nal actors are compiled in a specific manner. This example simply illus- 
trates how one might implement external actors. The desired behavior of 
an external actor is to as follows: 

• simply hold all communications sent to it until the system is composed 
with another that contains the actor in question. 

• respond to a communication telling it to forward all its mail to the 
actual actor when the composition is carried out. 

In response to an external declaration, we actually create an actor which 
will exhibit the above behavior. 

The code for an implementation can be given as follows. Assume that 
an actor called buffer is simultaneously created and, appropriately enough, 
buffers all communications until it accepts a communication telling it to 
forward them to a given mail address. Such a buffer could be specified as 
a queue using a linked list in a manner analogous to the implementation 
of the stack given above. One could also be a bit perverse and specify the 
buffer as a stack without changing the correctness of its behavior (recall 
the arrival order nondeterminism of the communications). As a stack, the 
behavior of the buffer would be given as below: 
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Buffer with acquaintances content and link 

if operation requested is release A content /NIL then 
send content to customer 
send release request with customer to link 
become customer 
if operation requested is hold then 

let B be a new buffer with acquaintances content and link 
{ become new buffer with acquaintances new-content and B } 

Assume for the purposes of simplification that a protocol for specifying 
a communication to become the actor at the mail address m exists and 
that such a communication has the form become m, where m is the mail 
address of the actor to which the mail should be forwarded. The behavior 
of an external actor is specified as below: 

* 

extern with acquaintances buffer 

if the communication is become customer 
then become customer 

send release request with customer to buffer 
else send hold request with customer to buffer 



3.3 Minimal Actor Languages 

In this section, we give the syntax for two minimal languages, SAL and 
Act. The programming language SAL has been developed for pedagogical 
reasons and follows an algol like syntax. Act is related to the languages im- 
plemented by the Message-Passing Semantics Group at M.I.T. and follows 
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a lisp-like syntax. Act can be considered as a kernel for the ActS language 
[Hewitt, et al 84]. One basic difference between SAL and Act is in how they 
bind identifiers and would provide for their authentication. SAL would use 
conventional type-checking whereas Act uses an elaborate description sys- 
tem based on a lattice structure for reasoning with the descriptions. For 
the rest of the thesis we will use expressions whose syntax we have already 
given in the previous section. For simple examples we will use SAL's syn- 
tax. However, it is not necessary to look at the details of the syntax in this 
section: the only feature of SAL's syntax that the reader needs to know is 
that the acquaintance list is enclosed in (. . .) while the communication list 
is enclosed in [. . .]. 

Notation. The usual Backus-Naur form is used. In particular, (...) en- 
closes nonterminal symbols. We use darker letters for the terminals and id 
for identifiers. {...} is used to enclose optional strings, and a superscripted 
* indicates or more repetitions of the string are permissible. When a 
reserved symbol, such as {, is underlined, it stands for itself and not for its 
usual interpretation. 

3.3.1 A Simple Actor Language 

We give the syntax for the kernel of SAL. Behavior definitions in a SAL 
program are declarative in the the same sense as procedure declarations in 
an algol-like language: behavior definitions do not create any actors but 
simply identify a identifier with a behavior template. Actors are created by 
new expressions whose syntax is the same as that given in the last section. 
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The syntax of behavior definitions is as follows: 

(behavior definition) ::= 

def (beh name) ( (acquaintance list) ) [(communication list)] 

(command)* 
end def 

Quite often the identifiers to be bound depend on the kind of commu- 
nication or acquaintance list: For example, if the communication sent to a 
bank is a withdrawal request then the communication must also specify the 
amount to be withdrawn; but if the communication is a request to show 
the balance, then it should not specify any amount. We follow the variant 
record structure of Pascal [Wirth 72] to deal with the variability of the 
identifier bindings. Basically, we branch on the value of an identifier called 
the tag-field and depending on the value of the tag-field, different identifier 
bindings are expected. The value of tag-field is called a case label. 
The syntax of the parameter lists is as follows: 



(parameter list) 
(var list) 
(variant) 



:= {id | (var list) } \ { , id \ , (var list) }* j e 
:= case (tag- field) of (variant)^ end case 
:= (case label) : (parameter list) 



where id is an identifier, e is an empty string (in case the parameter list 
is empty), the tag field is an identifier, and the case label is a constant 
(data- value) . The example below illustrates the use of parameter lists. A 
communication list in the behavior definition of a bank account is given. 
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case request of 

deposit 

withdrawal 

balance 
end case 



( customer , amount ) 
( customer , amount ) 
( customer ) 



Thus a communication [deposit , Joe , $50.00], where Joe is the mail ad- 
dress of some actor, would be an appropriate communication to send to a 
bank account created using the above behavior definition. 

We avoid specifying any type structure in our programming language 
for the sake of simplicity. It is not difficult to specify one: All we would 
have to do is use type declarations with the every identifier. Static type 
checking could be performed when the code is compiled to make sure that 
the identifiers are used correctly in the commands (with respect to their 
types). For example, identifiers used as targets must have the type mail 
address. Dynamic type-checking can be used whenever a new actor is ac- 
tually created: it would check if the parameters are correctly instantiated. 
Dynamic type-checking would also have to be used when a communication 
is accepted. 

(command) ::= if (logical expression) then (command) 

{ else (command) } fi | 
become (expression) | 

(send command) | (let bindings) {command} 
(behavior definition) \ (command)* 

The syntax is for the most part quite obvious. We have already defined 

behavior definitions above. Note that the scope of an identifier bound by 
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a behavior definition is lexical. The syntax for send command was given in 
the last section. It is simply: 

(send command) ::= send (communication) to (target) 

let bindings allow one to use an abbreviation for an expression. There is 
no mutual recursion unless new expressions are being bound; in the latter 
case, the actors created can know each others mail addresses. The syntax 
for let bindings is as follows: 

(let bindings) :~ let id =■ (expression) 

and id = (expression) 



We give only one example of a behavior definition in SAL to illustrate the 
flavor of the syntax. The code below is for an actor which behaves like a 
stack-node discussed in example 3.2.3 (§3.2). 

def stack-node (content, link ) 

[ case operation of 
pop : (customer) 
push : (new-content) 

end case] 
if operation = pop A content ^ NIL then 

become link 

send content to customer 
fi 
if operation = push then 

let P — new stack-node (content, link) 

{ become new stack-node (new-content , P)} 
fi end def 
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Note that we assume NIL is a predefined value and SINK is the mail address 
of some actor. A node can be created by a new command of the form given 
below. 

let p = new stack-node (NIL, SINK) 

The node created will subsequently serve as the receptionist for the stack 
since the mail address bound to p will always represent the mail address of 
the top most node of the stack. 

3.3.2 Act 

The language Act is a sufficient kernel for the ActS language which is 
a descendant of ActS [Theriault 83]. One basic distinction between Act 
and SAL is that the former uses a keyword-based notation while the latter 
uses a positional notation. The acquaintance list in Act is specified by 
using identifiers which match a pattern. The pattern provides for freedom 
from positional correspondence when new actors are created. Patterns are 
used in pattern matching to bind identifiers, and authenticate and extract 
information from data structures. The simplest pattern is a bind pattern 
which literally binds the value of an identifier to the value of an expression in 
the current environment. The syntax of pattern matching is quite involved 
and not directly relevant to the our purposes here. We therefore skip it. 

When an actor accepts a communication it is pattern-matched with the 
communication handlers in the actor's code and dispatched to the handler 
of the pattern it satisfies. The bindings for the communication list are 
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extracted by the pattern matching as well. We do not provide the syntax 
for expressions except to note that the new expressions have the same 
syntax as in §3.2 namely the keyword new followed by an expression. The 
syntax of behavior definitions in Act programs is given below. 

(behavior definition) : : = 

( Define ( new id { (w ith identifier (pattern)) }*) 
(communication handler)*) 

(communication handler) : :'= 

( Is-Communication (pattern) do (command)*) 

The syntax of commands to create actors and send communications is 
the same in actor definitions as their syntax at the program level. The 
syntax of the send-to command is the keyword send-to followed by two 
expressions. The two expressions are evaluated; the first expression must 
evaluate to a mail address while the second may have an arbitrary value. 
The result of the send-to command is to send the value of the second 
expression to the target specified by the first expression. 

(command) ::= (let command) | (conditional command) | 
(send command) | (become command) 

(let command) ::= (let ((let binding)*) do (command)*) 

(conditional command) : := (if (expression) 

( then do (command)*) 
( else do ( command)*)) 
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(send command) ::= ( send-to (expression) ( expression)) 
(become command) ::= (b ecome (expression)) 

The example of a stack-node definition from §3.2 is repeated below. 
For simplicity, we skip all error handling code. Note the keywords in the 
acquaintance and communication lists. These keywords allow a free order 
of attributions when the actors are created or when communications are 
sent. All the bindings we give are simple; in general the bindings can be 
restricted to complex patterns which allow authentication of the data by 
pattern matching. 



( define ( new stack-node ( with content =c) 

( with next-node =next)) 

( Is-Communication (a pop (with customer =m)) do 
(if (NOT (= c empty-stack)) 
( then ( become next) 

( send-to (m) (a popped-top ( with value =c)))))) 

( Is-Communication (a push ( with new-content =v)) do 
( let ( x = new stack-node ( with content c) 

( with next-node next)). 
do (become new stack-node ( with content v) 
( with next-node x))))) 



Chapter 4 



A More Expressive Language 



In this chapter, we will define some higher-level constructs that make the 
expression of programs somewhat simpler. The purpose of this exercise is 
two-fold: firstly, we wish to build a somewhat richer language, and secondly, 
we ilhistrate the versatility of the constructs in a minimal actor language. 
For purposes of brevity, we will use SAL in simple examples. In more in- 
volved examples, we simply use pseudo-code. The issues discussed in this 
chapter include: developing a notation to represent functions whose ar- 
guments are supplied by communications from several different actors; the 
question of delegation which arises when determining the replacement actor 
requires communicating with other actors; the meaning and representation 
of sequential composition in the context of actor system; and lastly, the 
implementation of delayed and eager evaluation for arbitrary expressions. 
The interest in such evaluation strategies stems in part because they are 
interesting ways to demonstrate the utility of mapping values like numbers 
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into a corresponding set of actors. 

4.1 Several Incoming Communications 

One of the simplest questions one can ask is what the representation of 
functions of several different inputs is going to be. If all the values needed 
to evaluate a function are to be received from the same actor, and at the 
same time, then there is no issue because communications in the kernel 
language are defined as a list of values. In general, however, carrying out 
some computation may require values from different actors. An actor need 
not know who the sender of the communication it is currently processing is. 
Modelling the above situation requires using some special protocols. The 
specifics of the construction are dependent on the type of scenario in which 
the multiple inputs are required. 

4.1.1 A Static Topology 

There are two distinct possible scenarios for an actor representing a func- 
tion of several arguments. If the sender is irrelevant, then the actor simply 
becomes an actor which responds appropriately to the next incoming com- 
munication. If the senders are relevant but static, as in dataflow languages, 
then we can represent the function as a system of actors: one actor as 
the receptionist for each sender and one actor that does the final function 
evaluation. Each receptionist buffers communications until it receives a 
ready communication from the function- apply actor, and then it sends the 
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function- apply actor another communication together with its own mail ad- 
dress. The mail addresses serve to identify the sender. A concrete picture 
for such a function- apply is an agent on an assembly line which is putting 
"nuts" and "bolts" together and needs one of each to arrive in order to 
fasten them before passing the result on. The receptionists act to buffer 
the "nuts" and "bolts." 

Consider the simple case of a function-apply actor which needs two 
inputs and sends the resiilt to an actor at the mail address m, as shown 
in Fig. 4.1. We assume actors at mail addresses mj and m 2 act to buffer 
incoming arguments and are the receptionists for this system of three actors. 
The actor at m is an external actor. The program for the actor to evaluate 
the function / can be given as below. 

We give two mutually recursive definitions. Only one actor need be 
created using the two-inputs-needed definition. The behavior of this actor 
will be alternately specified by one or the other of the definitions. One 
observation that can be made is that the mutual recursion in the definitions 
is simply to make it easier to understand the code: It would be entirely 
possible to write a single definition to achieve the same purpose. The 
alternate definition would use an acquaintance and branch on its value to 
the two possible behaviors. 

def two-inputs-needed (mi , m% , m) [ sender , arg ] 

if sender = mi 

then become new one -input- needed (mi, mi, second, arg) 
else become new one-input-needed (mi, m-i, first, arg) 

fi end def 
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Figure 4.1: A fixed topology for a two input function. 



def one-input-needed (mi, rri2, m, new-arg-position, old-arg) 
[ sender , arg ] 
let k = ( if new-arg-position = second then / (old-arg , new-arg) 
else / (new-arg , old-arg) fi ) 
{ send [ k ] to m } 
send ready to mi 
send ready to m 2 

become new two-inputs-needed (mi , m<i) 
end def 
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The function- apply actor which needs two inputs from actors m* and m,2 can 
be created by the expression new two-inputs-needed (raj, m-i). We assume 
that the actor ra is defined in the lexical scope of the new expression. 

4.1.2 A Dynamic Topology 

A more interesting case of a many argument function is one in which the 
senders can vary. One frequently useful form occurs when more input to 
complete some computation may depend on the segment of the computa- 
tion that has been carried out so far. Such a situation represents a dynamic 
topology of the interconnection network of actors. For example, an interac- 
tive program may need more input to continue with some transaction. The 
source of the input may vary: the program may sometimes get the input 
off some place on a disk, or perhaps from a magnetic tape, or a. user. A 
static topology where all the communications are received from the same 
senders before the computation starts, or even during it, will not work in 
this case. 

The general form for implementing requests for input from some par- 
ticular actor is a call expression, which has the syntax: 

call g [k] 

where A; is a communication and g is an identifier bound to a mail address. 
The value of the call expression is the communication sent by g as the reply 
when it accepts the present communication k. One way to picture the flow 
of the computation is given in Fig. 4.2. However, the figure is somewhat 
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misleading as a representation of what actually occurs in an actor system. 
The actor / does not (necessarily) have to wait for the reply from the actor 
g: a customer can be created which will continue processing when the reply 
from the actor g arrives. While the customer is "waiting" for the reply 
from g, the actor / may accept any communications pending in its queue. 




S 



Figure 4.2: The behavior of actor f in response to a communication may be 
a function of a communication from the actor g. 



The use of customers to implement continuations is more accurately 
portrayed in Fig. 4.3. This figure may be compared to the example of the 
recursive factorial in §3.2. There is some sequentiality, modeled by the 
causality ordering of the events, in the course of the computation triggered 
by a communication to the actor /. There is a degree of concurrency 



as 



CHAPTER 4. A MORE EXPRESSIVE LANGUAGE 72 

well. If the call expression occurs in the following context in the code for /: 

S' let x = ( call g[k] ) {S} S" 

then the actions implied by S' and S" can be executed concurrently with 
the request to g. Moreover, as discussed above, we do not force the actor / 
to wait until the reply from the actor g is received. The actor / would be 
free to accept the next communication on its mail queue, provided it can 
compute its replacement. 1 The customer created to carry out the actions 
implied by the command S will wait for the reply from the actor g. 

Notice that the general scheme for representing requests is analogous to 
our earlier implementation of the factorial actor. Using a call expression, 
the program for a recursive factorial may be written as below: 

t 

def exp Rec-Factorial ( ) [ n ] 
become new Rec-Factorial ( ) 
if n = 

then reply [l] 

else reply [ n * (call self [n — 1] ) ] 
fi end def 

We use def exp instead of def so that it is clear that the actor will return 
a reply to a customer that is implicit in all communications accepted. The 
incoming communication will have the form: 



1 We will discuss the case where an actor can not compute its replacement without further 
input in the next section. 
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Figure 4.3: The behavior of actor f is defined by program with a call ex- 
pression which requests more input. Some of the events are activated by the 
reply to a customer. 



[m ,k u ...,kj\ 

but our syntax explicitly shows only [fcj, . . . , kj\. The mail address m is 
bound when the expressional actor gets a communication. A translator can 
insert the customer and subsequently map the command reply [ x ] into the 
equivalent command: 

send [ x } to m 

The actor at m will be the customer which will continue the transaction 
initiated at the time of its creation. Comparing the above code with that 
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of factorial in the previous chapter (see Fig. 3.4) should make it clear how 
the behavior of the appropriate customer can be deduced: essentially, the 
segment of the environment which is relevant to the behavior of the cus- 
tomer has to preserved; a dynamically created customer can do this. A 
SAL compiler whose target language is the kernel of SAL can translate the 
above code to one in which the customer creation is explicit. Also note that 
only one reply command may be executed (in response to a single request). 

Thus a purely expression oriented language can be embedded in SAL 
(or equivalently in Act). The concurrency in such a language is inherent 
and the programmer does not have to worry about the details related to 
creating customers for implementing continuations. Another advantage to 
the "automatic" creation of customers is that it provides protection against 
improper use by the programmer, since the programmer has no direct access 
to the mail address of the customer created. 

There is one aspect of the expression oriented language that may be dis- 
turbing to the functional programming aficionados: namely, the presence 
of side-effects implicit in the become command. Recall that the ability to 
specify a replacement behavior is necessary to model objects with changing 
local states. The become command provides a mechanism to do so. The 
become command is actually somewhat analogous to recursive feedback in 
a dataflow language. This similarity (and the differences) will be discussed 
in greater detail in chapter 6. 
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4.2 Insensitive Actors 

When an actor accepts a communication and proceeds to carry out its 
computations, other communications it may have received must be buffered 
until the replacement behavior is computed. When such a replacement 
actor is known, it processes the buffered communications, as well as any 
new ones received. The precise length of time it takes for an actor to 
respond to a communication is not significant because no assumption is 
made about the arrival order of communications in the first place. 2 

However, the desired replacement for an actor may depend on com- 
munication with other actors. For example, suppose a checking account 
has overdraft protection from a corresponding savings account. When a 
withdrawal request results in an overdraft, the balance in the checking ac- 
count after processing the withdrawal would depend on the balance in the 
savings account. Thus the checking account actor would have to commu- 
nicate with the savings account actor, and more significantly the savings 
account must communicate with the checking account, before the new bal- 
ance (and hence the replacement behavior) is determined. The relevant 
communication from the savings account can not therefore be buffered un- 
til a replacement is specified! 

We deal with this problem simply by defining the concept of an in- 
sensitive actor which processes a type of communication called a become 
communication. A become communication tells an actor its replacement 



2 Communication delays are an important performance issue for a particular realization 
of the abstract actor arclutecture. Our focus here is restricted to semantic questions. 
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behavior. The behavior of an insensitive actor is to buffer all communica- 
tions until it receives a communication telling it what to become. Recall 
that external declarations were similarly implemented in Example 3.2.3. 

First consider what we would like the behavior of a checking account 
to be: if the request it is processing results in an overdraft, the checking 
account should reqiiest a withdrawal from its savings account. When a 
reply to the request is received by the checking account, the account will 
do the following: 

• Reply to the customer of the (original) request which resulted in the 
overdraft; and, 

• Process requests it subsequently received with either a zero balance 
or an unchanged balance. 

Using a call expression, we can express the fragment of the code relevant 
to processing overdrafts as follows: 

let r -- (call my-savings [ withdrawal , balance — amount ]) 
{ if r = withdrawn 

then become new checking- acc(0, my-savings) 
else become new checking-acc (balance , my-savings) 
fi 
reply [r] } 

To show how a call expression of the above sort can be expressed in 
terms of our kernel, we give the code for a bank account actor with overdraft 
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protection. Again the code for the customers and the insensitive actors need 
not be explicitly written by the programmer but can instead be generated 
by a translator whenever a call expression of the above sort is used. That 
is to say, if a become command is in the lexical scope of a let expression 
that gets bindings using a call expression, then the translator should do the 
work explicitly given in the example below. Not requiring the programmer 
to specify the behavior of the various actors created, such as the insensitive 
bank account and the customer to process the overdraft, protects against 
erroneous communications being sent to these actors. It also frees the 
programmer from having to decide her own protocols. 

A bank account with an overdraft protection is implemented using a 
system of four actors. Two of these are the actors corresponding to the 
checking and savings accounts. Two other actors are created to handle 
requests to the checking account that result in an overdraft. One of the 
actors created is simply a buffer for the requests that come in the checking 
account while the checking account is insensitive. The other actor created, 
an overdraft process, is a customer which computes the replacement be- 
havior of the checking account and sends the reply to the customer of the 
withdrawal request. We assume that the code for the savings account is 
almost identical to the code for the checking account and therefore do not 
specify it here. The structure of the computation is illustrated by Fig. 4.4 
which gives the actor event diagram corresponding to a withdrawal request 
causing an overdraft. 

The behavior of the checking account, when it is not processing an over- 
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<hold> 



<release> 



checking-acc 



savings-acc 




<requesl> 



Figure 4.4: Insensitive actors. During the dashed segment the insensitive 
checking account buffers any communications it receives. 



draft, is given below. When the checking account accepts a communication 
which results in an overdraft, it becomes an insensitive account. 



CHAPTER 4. A MORE EXPRESSIVE LANGUAGE 79 

checking-acc (balance , my-savings) [(request)] 

if (deposit request) 
then become new (checking-acc with updated balance) 
send (receipt) to customer 

if (show-balance request) 
send [balance] to customer 

if (withdrawal request) then 

if balance > withdrawal-amount 

then become new (checking-acc with updated balance) 

send (receipt) to customer 
else let 6 = new buffer 

and p = new overdraft-proc 
{become new insens-acc (b,p) } 
send (withdrawal request with customer p) to my-savings) 

The behavior of an "insensitive" bank account, called insens-acc, is 
quite simple to specify. It is given below. The insensitive account forwards 
all incoming communications to a buffer unless the communications is from 
the overdraft process it has created. 3 The behavior of a buffer is similar 
to that described in Example 3.2.3. The buffer can create a list of com- 
munications, until it receives a communication to forward them. It then 
forwards the buffered communications and becomes a forwarding actor so 
that any communications in transit will also get forwarded appropriately. 



3 Due to considerations such as deadlock, one would program an insensitive actor to 
be somewhat more "active" (see §6.1). Good programming practice in a distributed 
environment require that an actor be continuously available. In particular, it should be 
possible to query an insensitive actor about its current status. 
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insens-acc (buff er , proxy) [request , sender] 

if request = become and sender = proxy 
then become (replacement specified) 
else send (communication) to buffer 

Finally, we specify the code for a customer to process overdrafts. This 
customer, called overdraft-process receives the reply to the withdrawal re- 
quest sent to the savings account as a result of the overdraft. The identifier 
self is bound, as always, to the mail address of the actor itself (i.e., the actor 
whose behavior has been defined using the given behavior definition). The 
response from the savings account may be a withdrawn, deposited, or com- 
plaint message. The identifier proxy in the code of the insensitive account 
represents the mail address of the over-draft process. The proxy is used to 
authenticate the sender of any become message targeted to the insensitive 
actor. 

overdraft-proc (customer , my-checking , my-savings , 

checking-balance) [(savings-response)] 
send [ become , self] to my-checking 
send [(savings-response)] to customer 
if (savings response is withdrawn) 

then become new checking-acc (0 , my-savings) 

else become new checking- acc(checking-balance , my-savings) 
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4.3 Sequential Composition 

In the syntax of our kernel langtiage, we did not provide any notation for 
sequential composition of commands. The omission was quite intentional. 
Although sequential composition is primitive to sequential machines, in 
the context of actors it is generally unnecessary. Recall that the primitive 
actor carries out only three sorts of actions: namely, sending communica- 
tions, creating actors, and specifying a replacement behavior. The order 
of these actions is immaterial because there is no changing local state af- 
fecting these actions. Furthermore, the order in which two communications 
are sent is irrelevant because, even if such an order was specified, it would 
not necessarily correspond to the order in which the communications were 
subsequently received. 4 

There are some contexts in which the order of evaluation of expressions 
seems sequential even in the kernel of SAL. The two obvious places are 
conditional expressions and let expressions. A conditional expression must 
be evaluated before any of the commands in the body can be executed. 
Such evaluation can not be done at compile time. However, the entire con- 
ditional command can be executed concurrently with any other commands 
at the same level. One can think of each command as an actor to which 
a communication is sent with the current bindings of the identifiers. The 
"command actor" in turn executes itself in the environment provided by 
the communication. 



4 Unless the two communications are sent to the same target, there may not be a unique 
ordering to their arrival. See the discussion in Section 2.2. 
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A let command, unless it is binding a new expression, is nothing more 
than an abbreviation that can be removed by the compiler if desired. A 
translator can substitute the expression for the identifier whcreever the 
identifier is used (in the scope of the let binding). 

A more interesting case is that of let commands binding new expressions. 
New expression bindings serve as abbreviations for behaviors instead of val- 
ues. However, the behavior associated with an identifier is not necessarily 
constant. In an abstract sense, the identifier (in its scope of use) always 
denotes the same object. For example, a bank account refers to the same 
bank account even though the behavior of the bank account is a function 
of the balance in it. 

Let bindings have another characteristic: They may be mutually re- 
cursive since concurrently created actors may know of each other. The 
question arises in what sense the behavior of an actor depends upon the 
other actors. The only requirement is that concurrently created actors may 
know each others mail address. This in turn means that the mail addresses 
of each of the actors should be known before any of the actors are actu- 
ally created (since the behavior of each is dependent on other actors' mail 
addresses). The operational significance of this is quite straight-forward. 

Not withstanding their absence in the kernel of our actor language, 
sequential composition of commands can be meaningful as a structural 
representation of certain patterns of computations. Sequential composition 
in these cases is a result of causal relations between events. For example, 
consider the commands Si and S2 below: 
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Si = send [ call g [x] ] to / 
S 2 = send [ call g [y] ] to / 

then the sequential composition of Si with S2 has a very different meaning 
than the concurrent composition of the two commands because the effect of 
accepting communication [x] may be to change the actor g's subsequent be- 
havior. Thus sequential composition can result in only some of the possible 
order- of events inherent in the concurrent composition. 

Sequential composition of the above kind is also implemented using 
customers. The command S = Si ; 52 is executed concurrently with other 
commands at the same level. To execute S, the actions implied by the 

command Si are executed, including the creation of a customer to handle 

o 

the reply from g. When this customer receives the reply from g, it carries 
out the other actions implied by Si as well executing S2. 

Notice however that if Si and S2 were commands to simply send com- 
munications to g, then no mechanism for any sequential composition of the 
two actions implied would be definable in our kernel language. Nothing 
signals the end of any action at an actor other than the causal relations 
in the events. For example, causality requires that the actions of an actor 
must follow the event that creates it. The conclusion to be drawn is that 
concurrent composition is intrinsic in a fundamental and elemental fashion 
to actor systems. Any sequentiality is built out of the underlying concur- 
rency and is an emergent property of the causal dependencies of events in 
the course of the evolution of an actor system. 
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4.4 Delayed and Eager Evaluation 

In this section, we will develop the model of actors in which all expressions, 
commands and communications are themselves considered to be actors. We 
will call this model of actors the universe of actors model. The universe 
of actors model is useful for defining a language that is the actor equiva- 
lent of a purely expressional language. Specifically, the universe of actors 
model permits an easy (and efficient) implementation of the various expres- 
sion evaluation mechanisms, such as delayed and eager evaluation, using 
message- passing. 

Computation in actor systems is initiated by sending communications to 
actors that are receptionists . A single behavior definition in fact represents 
a specification of a system of actors with one of them as the receptionist 
for the system; the behavior of this receptionist is to execute a sequence of 
commands concurrently. We can consider each command to be an actor and 
the receptionist, upon accepting a communication, sends each command a 
message to execute itself with the current environment specified by the 
communication sent. The command will in turn send communications to 
expressions and create customers to process the replies. This process must, 
naturally, be bottomed out at some point by actors which do not send any 
"requests" to other actors but simply produce "replies." Hence, we need a 
special kind of actor, called a primitive actor, with the characteristic that 
some of these primitive actors need not (always) rely on more message- 
passing to process an incoming communication. Furthermore, primitive 
actors have a pre-defined behavior which never changes (i.e., the behavior 
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is unserialized). Which actors are defined as primitive depends on the 
particular actor system. 

4.4.1 Primitive Actors 

Primitive actors are used in order to "bottom-out" a computation. 5 Hence, 
the set of primitive actors must include the primitive data values and the 
basic operations on them. In particular, simple data objects such as inte- 
gers, booleans and strings must be considered primitive. When an integer 
is sent a message to "evaluate" itself, it simply replies with itself. To 
carry out any computation, primitive operations, such as addition, must be 
pre-defined. There are various mechanisms by which a consistent model, 
incorporating primitive operations, can be developed: one such scheme is 
to also define operations such as addition to be primitive actors. 

Our bias, however, is to encapsulate data values and the operations valid 
on the data into uniform objects. Hence, we define each integer as an actor 
which may be sent a request to add itself to another integer. The integer 
would then reply with the sum of the two integers. In fact an integer, n may 
be sent a request to add itself an arbitrary integer expression, e. In this 
case one must also send the local environment (which provides the bindings 
for the identifiers in e). The bindings of the identifiers will, of course, be 
primitive actors. One way to understand this notion is to notice that the 
expression e is really equivalent to call e [env] where env is the environment 



5 Theriault [83] used the term rock-bottom actors to describe these actors and the material 
on primitive actors closely follows his implementation in Act2. 
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in which the evaluation of the expression is to be performed. If e is an 
integer constant, it will reply with itself and, subsequently, n will reply 
with the correct sum. Specifically, the behavior of the expression e + n, in 
response to a request to add itself to the expression e in the environment 
env, can be described as: 

let x = call e [ env ] 

{ reply [ n + x ] } 

If e is not an integer but an integer expression, a call to it must result in an 
integer. Thus the meta-circular behavior of the expression, e = e^ + e-i, is 
to send evaluate messages to each of the expressions ei and e^ and to then 
send a message to the first expression (which would now have evaluated to 
the primitive actor that corresponds to the value of ei) to add itself to the 
actor the second expression evaluates to. 

Notice that we use integers, and expressions, as though they were iden- 
tifiers bound to mail addresses, and, indeed, as actors they are. To under- 
stand this concept, consider the relation between the numeral 3 and the 
number 3. For our purposes, in the universe of actors model, the identifier 
3 is bound to the mail address of the actor 3. Since 3 is a primitive actor, 
its behavior is pre-defined. Furthermore, the behavior of the actor 3 never 
changes (such a behavior is called an unserialized). 

There may be more than one actor 3 in a program: the identifier 3 is 
completely local to the scope of its use. However, the identifier 3 has been 
reserved for a particular functional (unserialized) behavior and may not be 
used differently by the programmer. One useful implication of the fixed 
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behavior of an integer like 3 is that it does not really matter how many 3's 
there are in a given actor system, or whether two 3's in an actor system 
refer to the same actor 5 or different ones. Ergo, when a communication 
contains the actor 5, it is an implementation decision whether to "copy" 
the mail address of the actor 3 or whether to copy the actor itself: the latter 
possibility is useful for maintaining locality of reference in message-passing 
for efficiency reasons. 6 To put it another way, the unserialized nature of 
primitive actors implies that there is no theoretical reason to differentiate, 
between the expression new 3, and simply 3. 

4.4.2 Delayed Evaluation 

In functional programming, delayed evaluation is useful for processing infi- 
nite structures by exploring at any given time, some finite segments of the 
structure. Using delayed expressions, the evaluation of a function is explic- 
itly delayed until another function "resumes" it. Thus, delayed evaluation 
is the functional equivalent of co-routines [Henderson 80]. 

In actor systems, it is not necessary to define delayed evaluation as a 
primitive: Since an actor becomes another actor as a result of processing 
a task, an actor already represents an infinite structure which unfolds one 
step at a time (in response to each communication accepted). Similarly, 
co-routines are one particular case of a concurrent control structure; actors 
allow one to define arbitrary concurrent control structures. Each control 



5 There is no notion of copying actors in the actor model. What we mean is create a new 
actor with the behavior identical to the current behavior of the (old) actor. 
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structure defines a graph of activations of processes and, as such, every 
control structure can be represented as a pattern of message-passing [He- 
witt 77]. The actor model allows dynamically evolving patterns of message- 
passing. Static control structures, such as co-routines, are a special (de- 
generate) case of the dynamic structures. 

As the above discussion suggests, delayed evaluation is a syntactic ex- 
tension to an actor language and not a semantic one. We define delayed 
expressions in order to make our purely expression oriented extension of 
SAL more expressive. The construct does not add any expressive power to 
the language. 

The expression delay e denotes the mail address of the expression e as 
opposed to the actual value of e. Recall that the expression e is equivalent 
to call e [env] where an expression denotes the mail address at which the 
expression resides (see the discussion about the universe of actors model in 
the previous section). 

For purposes of the discussion below, we assume that the environment 
is sent to any expression receiving a request. Now we have to decide what is 
meant by expressions which contain delayed expressions as subexpressions. 
For example, the expression : 

ej = e 2 * delay e 3 

is a product of an arithmetic expression and a delayed (arithmetic) expres- 
sion. When e 2 has been evaluated it receives the request [*, delay 63], where 
delay e 3 represents the mail address of the expression 63. Assume e 2 has 
evaluated to some integer n. The only feasible way of handling the expres- 
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sion ex then is to "return" (i.e., to reply with) its current local state, which 
will be equivalent to the expression n * e%. That is exactly what is done, 
except that the mail address of the expression e\ is returned, e^ has now 
become an actor behaviorally equivalent to the expression n * e 3 , and not 
the value of the expression. 

4.4.3 Representing Infinite Structures 

The delayed expressions we have defined so far do not really represent 
potentially infinite structures, because the expressions they define are not 
recursive. However, our def exp behavior definitions already provide for 
such recursive structures. In this section we explore this analogy with the 
help of a detailed example. We will present an example using a functional 
programming notation and using actors. Two different actor systems are 
defined with equivalent observable behavior; the second system uses actors 
that change their behavior. Furthermore, the second actor system does 
not use the list construction and separation operators. Thus the flavor 
of the two actor systems is quite different even though they have similar 
behaviors. 

The Example in Functional Programming 

The purpose of the following example is to define some functions which 
evaluate a given number of initial elements of an infinite list. The notation 
uses a functional form for the cons operation but not for the car or cdr. All 
functions are taken from Henderson [80]. Consider, the delayed expression 
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in the function integersfrom(n) below: 

integer sfrom(n) = cons(n , delay integersfrom(n + 1)) 

integer sfrom{n) is an example of such an infinite list, namely the list of 
all the integers greater than n. This list of may be evaluated only partially 
at any given point in time. The function first(i, x) defined below gives the 
first k arguments for an infinite list x whose cdr has been delayed. (In the 
functional program, one has to explicitly force the evaluation of a delayed 
list.) 

first (i, x) = if i=0 then NIL 

else cons (car x , first (i — 1 , force cdr x) ) 

Now we define two more functions which can be used to return the cumu- 
lative sum of all the elements of a list up to some ith element. The function 
sums(a, x) returns a list whose i£k element is the sum of the first i elements 
of the list x and the integer a. Finally, the function firstsums(k) uses the 
functions defined so far to return the list of initial sums of the first i positive 
integers. 

sums (a, x) = cons (a + carx , delay( sums (a + carx , force cdr x) ) 
firstsums (k) = first {k , sums(0, integer sfrom{l))) 

A System of Unserialized Actors 

Let us now define an actor system which produces the same behavior. We 
will do this in two different ways. First, we define a system of actors all 
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of whom have unserialized behaviors (i.e., they are always replaced by an 
identically behaving actor). We therefore give their definitions without any 
become commands in them. (Recall the default that an actor is replaced 
by an identically behaving actor if no become is found in its code). We will 
subsequently define a system of actors which uses serialized behaviors when 
appropriate. The idea behind defining two systems is to show the relation 
between actor creation and actor replacement. The systems also show the 
relation between delay and actor creation. 

Assume that the operations cons, car and cdr exist and are defined 
on actors representing lists, cons is sent the mail address of two actors 
and returns a list of the two mail addresses. It is important to note the 
equivalence of the mail address of a primitive actor and the actor itself. 
There are two possibilities for a list x: it may consist of a primitive actor 
(equivalently the mail address of a primitive actor) or it can be the mail 
address of an arbitrary list, car x equals 1 if a; is a primitive actor, or 
equivalently the mail address of a primitive actor, otherwise car x is the 
mail address of the first element of the list, cdr x is NIL if x is a primitive 
actor, and otherwise returns a mail address corresponding to the rest of the 
list. 

All the actors whose behavior is given by code below are expressions. 
We will not bother to enclose the definitions in def exp • • • end def since the 
definitions are all rather brief. There is no need delay or force operators: 
a delayed list is represented by the mail address of an actor representing 
that list. 
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The first function we define is integer sfrom(n). The behavior of an 
integersfrom(n) actor is that it responds to an evaluate reqtiest (i.e., a 
request of the form [ ] ) by replying with a list whose car is the integer n and 
whose cdr is the niciil address of an actor with the behavior integersfrom{n-\- 

integer sfrom(n) [] = reply [cons (n, new integersfrom(n + 1))] 

The behavior of an actor whose behavior is given by first ( ) is as follows: 
when it is sent a request [i,x], where i is an non-negative integer and x is 
an arbitrary list, it replies with the first i elements of the list. We assume 
that the list x is sufficiently long to have i elements. 

first( ) [i,x] = if i=0 then reply [ NIL ] 

else reply [cons (car x , call self [i — 1, cdr x]) ] 

Finally, we give the behavior definitions for the two remaining actors. 
firstsums() defines an actor whose behavior is to give a finite list whose iih 
element is the sum of the first i non-negative integers. The length of the list 
of sums in the reply is specified in the communication received. In order 
to create a system which returns the list of initial sums of non-negative 
integers, we need to create only a firstsums{ ) actor; all the other actors 
will be created by this actor. The actor created will always be the sole 
receptionist for such a system since no mail address is ever communicated 
to the outside. 

sums(a, x) [] = let 6 = a + can 

{ reply [ cons (6,new sums(b,cdr x))] } 
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firstsums( ) [k] = let p = new integer sfrom(l) 
and s = new sums(0,p) 
and / = new Jirst() 
{reply[call /[*,«]] } 

The fact that all the behaviors are unserialized implies that it is possible 
to use the same actors for different requests. Thus if an actor with behavior 
first( ) exists, it doesn't matter if a communication is sent to the same 
actor or to a new actor created with the behavior first(). The converse 
of this property is that an actor with unserialized behavior can never be a 
history-sensitive shared object. This same limitation is applicable to purely 
functional programs. 

A System With Serialized Actors 

We now attack the same problem with actors that may change their local 
state: i.e., actors that may be replaced by actors whose behavior is different 
than their own. The point of defining this system is to show the relation 
between actor creation and replacement. The example also illustrates the 
similarity between a delayed expression and a serialized actor. 

It should be noted that actors are in fact more general than expres- 
sions in functional programming. For one, actors, unlike expressions, may 
represent (history-sensitive) shared objects. For example, a bank account 
written as a function which returns a partly delayed expression will have 
returned an argument purely local to the caller. This means that such a 
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bank account can no t be shared between different users (or even between 
the bank manager and the account owner!). In dataflow architectures, 
the problem of sharing is addressed by assuming a special merge element. 
However dataflow elements have a static topology (see the discussion in 
chapter 2). 

The definitions below do not use cons, car, and cdr operations. Instead 
we simply construct and bind the communication lists. The behavior def- 
inition of integer sfromfn) is that it accepts a simple evaluate message, [ ], 
and replies with the integer n. However, the actor presently becomes an 
actor with the behavior integersfromfn+1). An actor with its behavior de- 
fined by sums(a,x) has two acquaintances, namely a and x. a is the sum 
of the first umpteen elements and x is the mail address of an actor which 
replies with the umpteen+1 element of the "list." The sums actor calls x 
and replies with the next sum each time it is called. 

The behavior definitions of first is similar to the previous section ex- 
cept that we use explicit call's. Note that the definition of firstsums( ) is 
identical to the one given above, and is therefore not repeated. 

integers-from(n) [ ] = reply [ n ] 

become new integers-from(n + 1) 

first( ) [i, x] = if i-0 then reply [ ] 

else reply [call x[], call self [i — l,x]] 

sums(a, x) [] = let b = a + call x [ ] 
{reply [b] 
become new sums(b, x) } 
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The concept of replacement provides us with the ability to define lazy 
evaluation so that same expression would not be evaluated twice if it was 
passed (communicated) unevaluated (i.e., if merely its mail address was 
sent). If lazy evaluation was desired, one could send communications con- 
taining the mail addresses of expressions, instead of the primitive actors the 
expressions would evaluate to. In this scheme, the message-passing disci- 
pline is equivalent to a call-by-need parameter passing mechanism, instead 
of a call-by-value which is the default in our definition of SAL. 

However, the point of actor architectures is not so much to merely 
conserve computational resources but rather to provide for their greedy 
exploitation — in other words, to spread the computation across a extremely 
large-scale distributed network so that the overall parallel computation time 
is reduced. At the same time, it would be inadvisable to repeat the same 
computation simply because of the lack of the ability to store it — a seri- 
ous problem in purely functional systems [Backus 77]. In the next section 
we provide a strategy for evaluation of expressions which satisfies these 
requirements. 

4.4.4 Eager Evaluation 

The inherent parallelism in actors provides many options for a greedy strat- 
egy in carrying out computations. The idea is to dynamically spawn nu- 
merous actors which will carry out their computations concurrently. These 
actors can exploit all the available resources in a distributed systems. We 
have already seen pipelining of the replacement actors as a mechanism for 
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increasing the speed of execution on a parallel architecture. In an actor 
language, the pipelining is made possible by the use of customers by which 
continuations are incorporated as first-class objects. 




Figure 4.5: Eager evaluation. The dotted line shows the acquaintance rela- 
tion. X creates Y and tells it about e while concurrently sending an evaluate 
message to e 



Another mechanism by which the available parallelism in an actor lan- 
guage can be exploited is by schemes for eager evaluation. To speed up the 
computation to its logical limits, or at least to the limit of the number of 
available processes in a particular network, one can create an actor with 
the mail addresses of some expressions (which have not necessarily been 
evaluated) as its acquaintances. So far, this is similar to how one would 
implement call-by-need. However, for eager evaluation we concurrently send 
the expression, whose mail address is known to the actor created, a request 
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to evaluate itself. Fig. 4.5 shows this pictorially. The net effect is that an 
actor Y which has been created may accept a communication even as the 
expression e which is its acquaintance is being evaluated concurrently. The 
expression subsequently becomes the primitive actor it evaluates to. Thus 
the evaluation of the same expression need not be repeated. 



Chapter 5 



A Model For Actor Systems 



A model for any collection of objects provides a map from the objects into 
equivalence classes that contain elements which are considered to be indis- 
tinguishable from each other. In other words, a model provides an abstract 
perspective in which the "irrelevant" details are ignored in establishing the 
equivalence of systems. A denotational model is one in which the meaning 
of a system can be derived from the meanings of its constituent parts. We 
will refer to this property as compositionality. 

The semantics of sequential programming languages has been rather 
successful in building denotational models of programs which abstract away 
the operational details of the sequential systems defined by the programs. In 
the case of conairrent systems, however, the requirements of compositional- 
ity have resulted in proposed denotational models which retain substantial 
operational information. The reason for this is as follows. Composition in 
concurrent systems is achieved by inter-leaving the actions of the systems 
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that are composed: thus the denotations for a system require the reten- 
tion of information about the intermediate actions of the system (see, for 
example, [Milner 80] or [de Bakker and Zucker 83]). 

In this chapter we will develop a model for actor systems based on 
semantics by reductions. The actor semantics follows a structured opera- 
tional style long advocated by Plotkin. In particular, we define transition 
relations which represent the evolution of an actor system as the computa- 
tions it is carrying out are unfolded. Two transition relations are necessary 
to capture the behavior of an actor system. The first of these, called a 
possible transition, represents the possible orders in which the tasks may 
be processed. The possible transition relation is, however, insufficient to 
capture the guarantee of mail delivery. We therefore define a second tran- 
sition relation, called subsequent transition, which expresses just such a 
guarantee. 

The plan of this chapter is as follows. The first section specifies a 
formal definition for the configuration of an actor system and states the 
requirements relevant to defining an operational semantics of actors. In 
the second section we map actor programs to the initial configurations they 
define. The last section discusses two kinds of transition relations between 
configurations. These transition relations provide an operational meaning 
to actor programs. 
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5.1 Describing Actor Systems 

The configuration of an actor system is described by the actors and tasks 
it contains. There is no implied uniqueness in the configuration of an actor 
system: different observers may consider the system to be in quite different 
configurations. This issue is discussed in greater detail in Section 5.3. To 
describe the actors in a system, we have to define their behaviors and their 
topology. Descriptions of actor systems are embodied in configurations and 
therefore we will first develop some notation to represent configurations. 
The definitions below assume that actor behaviors are well-defined — a 
topic we will discuss in §5.2. 

5.1.1 Configurations 

There are two components in a configuration: namely, the actors and the 
tasks. The tasks represent communications which are still pending; in other 
words, communications that have been sent but not yet accepted by the 
target. These communications may or may not have been delivered; they 
are simply yet to be processed. We keep equivalent tasks (i.e., those with 
the same communication and target) distinct by specifying a unique tag for 
each task in a configuration. 

Definition 5.1 Tasks. The set of all possible tasks, T , is given by 

T = IxMxK 

where I is the set of all possible tags, M is the set of all possible mail 
addresses, and K is the set of all possible communications. We represent 
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tags and mail addresses as finite sequences of natural numbers, separated 
by periods, and communications as a tuple of values. If r is a task and 
t — (t, m, k) then we call t the tag for the task r and m the target . 

We define a local states function to represent the behaviors of the actors 
from some view-point. Since'there are only finitely many actors in any given 
configuration, this is really a partial function on the set of all possible 
mail addresses. However, when appropriate, one can treat the local states 
function as a total function by defining an undefined behavior, called _L, and 
mapping all undefined elements to _L. For our immediate purposes, defining 
a total function is not necessary. In the definition below, we assume that a 
set of possible actor behaviors B exists. 

Definition 5.2 Local States Function. A local states function I is a 
mapping from the mail addresses of the actors in a system to their respective 
behaviors, i.e., 

I : M — ► B 

where M is a finite set of mail addresses (M C M), and B is the set of 
all possible behaviors, respectively. We represent the set of all local states 
functions by £. 

A configuration is defined as follows. A restriction on the tags of a config- 
uration (specified in the definition below) is necessary to ensure that there 
always exist transitions from a given configuration with unprocessed tasks. 
We wish to avoid any tag conflicts as an actor system evolves. 
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Definition 5.3 Configurations. A configuration is a two tuple (l,T), 
where I is a local states function and T is a finite set of tasks such that no 
task has a tag which is the prefix of another tag or mail address. 1 

Note that the set T in fact represents a function from the a finite set 
of tags to the cross product of mail addresses and communications. The 
degenerate case of the prefix relation is equality and thus no two tasks in 
a configuration may have the same tag. 

5.1.2 Requirements for a Transition Relation 

What any behavior definition gives us is a map from a finite list of variables 
to a "behavior." These variables are given specific values whenever any 
actor is created in the system. An actor's behavior specifies the creation 
of new tasks and actors as a function of a communication accepted. Newly 
created actors must have mail addresses that are unique and the different 
tasks in a system need to be kept distinct. 

A global scheme for assigning mail addresses to newly created actors is 
not a faithful representation of the concurrency inherent in an actor system 
although such a scheme would provide a simple mechanism for generating 
new mail addresses in much the same way as the semantics of block decla- 
rations in Pascal provides for the creation of new variables [de Bakker 80]. 
We will instead provide a distributed scheme for generating mail addresses. 

One can maintain the uniqueness of tasks by providing distinct tags 
for each and every task in an actor system. In fact, one purpose of mail 
1 The prefix relation is defined using the usual definition for strings. 
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addresses is quite similar to that of tags: mail addresses provide a way 
of differentiating between identically behaving actors. Mail addresses also 
specify a network topology on actors by allowing one to define a directed 
graph on them (the nodes in such a graph denote the actors). We will use 
the unique tags of a task to define more unique tags and mail addresses 
for the new tasks and actors created. Having defined a scheme which guar- 
antees the uniqueness of tags and mail addresses, we can transform the 
instantiations of the behavior definition into a transition relation from each 
actor and task to a system of actors and tasks. This transition relation can 
be extended meaningfully to a system of actors and tasks as long as mail 
addresses and tags can be generated in a distributed fashion and maintain 
their uniqueness as the system evolves. 

5.2 Initial Configurations 

Our goal is to map actor programs to the initial configurations they define. 
To do so we have to specify how the meaning of the various constructs in an 
actor program. We confine our consideration to minimal actor languages 
such as the kernel of SAL and Act defined in Section 3.2. Since all the 
extended constructs are definable in such minimal languages, and since 
the kernel is much simpler than any expressive extension, such a restricted 
focus is not only pragmatically desirable but theoretically sufficient . 
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5.2.1 Formalizing Actor Behaviors 

The behavior of an actor was described informally in Section 2.1.3. In a 
nutshell, we can represent the behavior of an actor as a function from the 
possible incoming communications to a 3-tuple of new tasks, new actors, 
and the replacement behavior for the actor. We give a domain for actors 
below. Since the given domain of actor behaviors is recursive, it is not 
immediately obvious that the behavior of an actor is well-defined: We can 
deduce from a simple cardinality argument (following Cantor) that not all 
functions of the form in definition 5.5 will be meaningful. 

There are two ways to resolve the domain problem for actors. The first 
solution is to use Scott's theory of reflexive domains [Scott 72] to map actor 
behaviors into an abstract, mathematically well-defined space of functions. 
Applying Scott's theory each actor program denotes a value in the specified 
abstract space. Such valuations, however, may or may not suggest a means 
of implementing an actor language. In fact, one can show that computation 
paths defined using the transition relation specify information system as 
defined in [Scott 82]. 

In the denotational semantics of sequential programs, a major advan- 
tage of the fixed-point approach has been the ability to abstract away from 
the operational details of the particular transitions representing the inter- 
mediate steps in the computation. The sequential composition of functions 
representing the meaning of programs corresponds nicely to the meaning of 
the sequential composition of programs themselves. This also implies that 
the meaning (value) of a program is defined in terms of the meaning of 
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its subcomponents [Stoy 77]. Furthermore, since sequential composition is 
the only operator usually considered in the case of deterministic, sequential 
programs, the fixed-point method is fully extensional [de Bakker 80]. 

Unfortunately, fixed point theory has not been as successful in providing 
extensional valuations of concurrent programs. The problem arises because 
of the requirements of parallel compositionality: Specifically, the history of 
a computation is not as easily ignored. We will return to this topic in 
Chapter 7. 

What we propose to do in this chapter is to provide a functional form 
for the behavior of an actor in a given program. Specifying the meaning 
of a program in these terms does not abstract all the operational details 
related to the execution of the code. These functions will in turn be used to 
define the initial configuration and the transitions between configurations. 
The representations are entirely intentional in character and thus provide 
constructive intuitions about the nature of computation in actor systems. 

Note that the semantics of actor programs developed in this section is 
denotational because the meaning of a program is built from the meaning 
of its constituent parts. We begin by defining actors and their behaviors. 

Definition 5.4 Actors. The set of all possible actors, A, is given by 

A = MxB 

where M is the set of all possible mail addresses (as above), and 8 is the 
set of all possible behaviors. 

The tag of the task processed by an actor a is used to define new tags 
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for the tasks, and new mail addresses for the actors, that are created by 
a in processing the task. Notice that there are only a finite number of 
tags and mail addresses possible. A recursive domain for actor behaviors 
is given below. 

Definition 5.5 Behaviors. The behavior of an actor, with the mail ad- 
dress ' 2, is an element of B , where 

B = (Ix{m}xK — + F.(7) x F„{A) x A ) 

where F S (T) is the set of all finite subsets of T and F S (A) is the set of finite 
subsets of A. Furthermore, let (3 be a behavior for an actor at mail address 
m, and t be the tag and k be the communication of the task processed, such 
that /3(k) = {T,A,i), where 

r={n,...,T n } 

A = {«i, •• •,<*„<} 
then the following conditions hold: 

1. The tag t of the task processed is a prefix of all the tags of the tasks 
created: 

V* (1 < i < n => Irrii G At 3fc, G K 3<- G I (r< = (W^rm, fc))) 

2. The tag t of the task processed is a prefix of all the mail addresses of 
the new actors created: 

Vt (1 < i < ri => 3/3,- G B 3t'i G I (a, = («.«■, A))) 
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3. Let I be the set of tags of newly created tasks and M be the set of 
mail addresses of newly created actors. Then no element of I U M is 
the prefix of any other element of the same set. 

4- There is always replacement behavior. 

3/3'eS( 7 = (m ( ^)) 

The example below is for illustrative purposes. The meaning developed 
in §5.2.2 will allow us to derive from the code the functional form given. 

Example 5.2.1 Recursive Factorial. The recursive factorial discussed 
in section 2 is an example of an unserialized actor. The code for such an 
actor is given in Section 3.3. The behavior of a recursive factorial actor at 
the mail address m, (m, <p), can be described as follows: 

p(t i m,[k 1 ,k 2 \) - 

({(t.l,k 2 ,[l))},0,{m,<p)) if h = 

{{(i.l,™,^ -M.2])}, {(i.2,t/£)}, (m,<p)) otherwise 
where m is the mail address of the factorial actor, t is the tag of the task 
processed. The behavior of the newly created customer can be described 
as 

V£(«\t.2,[n]) = <{(*M, * 2 , [n **!])}, 0, (*-2,£l)> 
where t.2 is the mail address of the newly created actor, and t' is the tag 
of the task it processes. ft± is bottom-behavior , which is equivalent to an 
infinite sink. Note that it can be shown in any actor system that this newly 
created actor will receive at most one communication, thus the behavior of 
its replacement is actually irrelevant. 
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5.2.2 The Meaning of Behavior Definitions 

Recall that nn actor machine embodies the current behavior of an actor. 
Conceptually, an actor machine is replaced with another, perhaps identi- 
cal, actor machine each time a communication is accepted by an actor. The 
behavior of an actor machine is quite simple: it involves no iteration, recur- 
sion, synchronization, or state change. The behavior is simply a function 
of the incoming communication and involves sending more communications 
to specified targets, creating new actors, and specifying a replacement ac- 
tor machine. 2 We will use the syntactic default in an actor program that 
whenever there is no become command in the code of an actor, then the 
replacement behavior is simply an identically behaving actor. One can now 
safely assert that all actors definable in an actor language like SAL specify a 
replacement behavior. Alternately, we could have decided that a behavior 
definition which did not provide a replacement in some case was simply 
meaningless. 

In this section, we closely follow the relevant notation and terminology 
from [de Bakker 80]. Each actor program consists of a finite number of 
behavior definitions which will form templates for all the behaviors of actors 
that may be created in the course of program execution. We will define the 
meaning of a behavior definition as a map from: 

• The mail address, self, of the actor whose behavior has been defined 
using the template; and 



2 The rest of this section is a technical justification for a well formed interpretation of 
actor hehaviors and may be skipped without loss of continuity. 
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• The variables in the acquaintance list of the behavior definition. 

And a map into a function mapping a task with target self into a three 
tuple consisting of: 

• A set of tasks; 

• A set of three tuples consisting of a mail address, a behavior definition, 
and a list of values; and, 

• A three tuples consisting of the mail address self, a behavior defini- 
tion, and a list of values. 

We carry out the construction formally. We first define the syntax for 
the class of primitive expressions. There are three kinds of primitive ex- 
pressions: integer, boolean and mail address expressions. These expressions 
will occur in different commands. The chiss Icon typically corresponds to 
identifiers such as 3, 4, — 1, . . ., while the class Jvar corresponds to the iden- 
tifiers used for integers in a program. Note that there is no class of mail 
address constants in the expressions of our language because the program- 
mer has no direct access to mail addresses. The primitive expressions given 
below are purely syntactic objects which will be mapped into mathematical 
objects by a valuation function. 

Definition 5.6 Syntax of Primitive Expressions. 

1. Let Jvar, with typical elements x,y, . . . , be a given subset of the class 
of identifiers, and Icon be a given set of symbols with typical elements 
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n, . . .. The class Iexp, with typical elements s, . . . , is defined by 

s ::= x | n \ s t + s 2 | • • • 

(Expressions such as Sy — s 2 ma 2/ '> e added.) 

2. Let Mvar, with typical elements a, . . . , be a given subset of the class 
of identifiers, E be an element of Dvar (defined later) and e±,. . . , e; 
be arbitrary expressions, then the class Mexp, with typical elements 
h, . . . , is defined by 

h ::= a \ new E(ei,. .. ,e t ) 

8. Let Bvar, with typical elements b, . . . , be a given subset of the class 
of identifiers, and Bcon be the set of symbols { true , false }. The 
class Bexp, with typical elements b, . . . , is defined by 

b ::= true | f alse | Si = s 2 | hi = hi \ -b \ • • • 

We now assume the existence of three classes of mathematical objects: 
namely, a class of integers, V, a class of mail addresses, M, and a class of 
truth values, W — {tt,ff}. The integers and the truth values have the 
usual operations associated with them, such as addition for integers. We 
assume that the concatenation operator works for the mathematical objects 
called mail addresses since the class of mail addresses will be identical to 
the class of tags and the latter will be suffixed to define new mail addresses. 

Let the set of primitive variables, Pvar, be the separated sum of integer, 
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boolean, and mail address variables. 3 Similarly, let P be the set of primitive 
values representing the separated sum of the integers, the truth values and 
the mail addresses. A local environment is defined as an element of: 

E : Pvar -» Pval 

There are three semantic functions that need to be defined to give a meaning 
to the primitive expressions. Given a local environment these functions map 
primitive expressions to primitive values. These functions are: 

V : Iexp -> ( E -> V ) 
W : Bexp -> ( E -♦ W) 
M : Mexp -» ( E -» M ) 

The definitions of the first two functions are by induction on the com- 
plexity of the arguments and have nothing to do with actor semantics in 
particular. We therefore skip them. We will define the meaning function 
below which will provide the valuation for new expressions. Essentially, 
new expressions evaluate to a new mail address. We will assume a single 
function it representing the separated sum of above three functions such 
that 7r maps each expression into its corresponding value given a particular 
local environment, a. 

We now give the syntax of commands, and using commands, the syntax 
of behavior definitions. The syntactic classes defined are called Grand and 



3 Strictly speaking the set Bvax is superfluous since boolean expressions can be defined 
without it. However, we will assume that all three kinds of variables exist and are 
distinct. 
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Bdcf. The syntax below is a slightly abbreviated form of the syntax used in 
SAL. The two noteworthy differences between SAL and the syntax below 
are as follows. First, we allow let bindings only for new expressions. The 
semantics of let bindings in other cases is quite standard, and in any case 
not absolutely essential to our actor programs. Second, we use new expres- 
sions, as opposed to arbitrary expressions, in all become commands. The 
semantic interpretation of becoming an arbitrary actor is simply to acquire 
a forwarding behavior to that actor (see §3.2.1). The behavior can thus be 
expressed as a new expression using a predefined forwarding behavior and 
specifying its acquaintance as the expression. The only reason for these 
simplifications is brevity. 

Definition 5.7 Syntax of Behavior Definitions. 

1. The class Cmnd with typical elements S, • ■ • , given by 

S ::= SJ /S 2 | if b then S t else S 2 | 

send [ci, . . . ,e,-] to a | become new E{e u ...,ei) j 
let ai = new Ei(ei, . . . ,e„) and . . . 

and a 3 =new Ej(e x , . . . , e i} .) { S } 

where the use of the identifiers corresponds to their reserved status 
above. The identifiers E, . . . , are used as defined below. 

2. Let Dvar be set of pre-defined symbols. The class Bdef with typical 
elements D, . . . , is given by 

D ::= def£( Pl ,...,p,)[p;,..., P ;]Senddef 
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The semantics of the class Cmnd is defined below. The semantics maps 
a given local environment into a 3-tuple representing tasks created, actors 
created and a replacement actor, respectively. Note that actors are simply 
denoted by a mail address, an element of Dvar, and a list of primitive values 
which will map into the primitive variables used in the behavior definition 
using the element of Dvar. We also assume that two primitive variables, 
namely se//and curr, of the class Mvar are defined by the local environment. 
self represents the mail address of the actor whose code contains the given 
command and curr represents the tag of the task being currently processed. 
The meaning function is defined on the complexity of the commands. We 
will not bother to define a complexity measure for the commands but will 
simply follow the syntactic definition. The details are trivial. Note that 
a represents the local environment and c[a/x] represents the environment 
which is equal to a except that it has the primitive value a for the primitive 
variable x. The operation y represents a component-wise union (i.e., the 
three components are union independently). 

The meaning function J maps each command in a given local environ- 
ment to a three tuple representing the communications sent, actors created 
and the replacement actor. The meaning of concurrent commands is the 
component-wise union of the commands themselves, i.e., the communica- 
tions sent are the communications sent by each and the actors created are 
the union of the actors created by executing each of the commands. Recall 
that there may be only one executable become command in the code of an 
actor for any given local environment. If the union ends up with more than 
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one replacement actor than it does not define an actor behavior. The main 
point of interest in concurrent composition is the suffixing of the current 
tags. This mechanism ensures that the new actors and tasks created by the 
actor will satisfy the prefix condition in definition 5.5. Assume that curr is 
initially bound to I on the left hand side of all the equations given below. 

7(S l //S 2 )(<7lt/currl) = 7{S l ){a{t.l/curr])\ ! )f{S 2 ){a[t.2/curr\) 

The meaning of the conditional command and the send command is straight- 
forward. The become command specifies the replacement, behavior by spec- 
ifying an identifier which will denote a behavior definition and a list of 
values which will partially determine the local environment in which the 
command in the definition is executed. 



7 (if b then Si else S 2 ) {a) = 



?(S t ){a) ifrr(b)=tt 
?(S2)(a) otherwise 



7{ send [ej, . . . , e;] to a )((r[i/c«rrj) = 

({t .1, *(a)(a) , [7r( ei )(a), . . . , w(e,-)(<7)]}, 0, 0) 

/(become new E(ei,. . . ,ei))(er[m/seJ/]) = 

(0, 0, {(m, £?(jr( ei )(a), . . . , 7r(e,)(ff))}) 

The creation of new actors is accomplished by new expressions and let 
bindings. We have to specify the new mail addresses for all concurrently 
created actors which may know each others mail address. The command in 
the scope of the bindings is also executed in an local environment where all 
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the identifiers for the actors are bound to the mail addresses of the newly- 
created actors. 

J(let a t = new E^ei,... ,e,,) and ... and 

a, = new E 3 (e u . . . ,e {j ) {S})(c[t/curr]) = J(5)(a')U 

(0, {a n : VI < n < j(a n = (t.n, E n (7r( ei )(a'), • • • , 7r( e ,J(cr'))}, 0) 

where a' = crlax/t.l, . . . ,a,j/t.j\ 

Now the meaning of a behavior definition is simply to modify the pro- 
gram environment by mapping each Dvar into the meaning of the com- 
mand. We skip the (simple) proof that a behavior definition defines be- 
haviors that satisfy the requirements of definition 5.5. The tag and mail 
address generation schemes we used were intended to satisfy these require- 
ments. The only other constraint of interest is that there be at most one 
executable become command. The behavior definition is simply not well- 
defined if its meaning violates this constraint. 4 

5.2.3 Mapping Actor Programs 

The basic syntax of a SAL program consists of behavior definitions and 
commands. The commands are used to create actors and to send them 
communications. 5 Now a program environment associates the identifiers in 
Dvar with the meaning of commands for each behavior definition in the 



4 In an implementation, we would generate an error message. 

5 We are ignoring for the present the receptionist and external actor declarations; although 

such declarations are useful for imposing a modular structure on the programs, they do 

not directly affect the transitions internal to the system. 
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program. All other members of Dvar are undefined and may not be used 
in the commands of a syntactically correct program. The program itself 
is a single command (recall that concurrent composition of commands is a 
command) and its meaning is given using the function J defined above with 
the local environment as the program environment. The technique used 
here is similar to that in used in [de Bakker 80] where procedure variables 
are defined in the denotational semantics of recursion. The syntax of a 
program can be given as follows: 

P ::= £>!...£>„ S 

where the .D.'s represent behavior definitions and S represents a command 
(which may, of course, be the concurrent composition of other commands). 
The variable curr is initially bound to 1. 

Note that none of the top level commands can be a become command be- 
cause the commands are not being executed by a given actor. Thus an actor 
program is mapped into a two tuple representing the initial configuration. 
A transition relation tells us how to proceed from a given configuration 
by, nondeterministically, 6 removing a task from the system and adding the 
effects of processing that task. The effects of processing a task are given by 
the behavior of its target, namely the actors and tasks the target creates 
and the replacement it specifies. 



6 We will return to the issue of the guaranteeing mail delivery in Section 5.3. 
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5.3 Transitions Between Configurations 

In a sequential machine model, the intuition behind transitions is that 
they specify what actions might occur "next" in a system. However in the 
context of concurrent systems, there is generally no uniquely identifiable 
transition representing the "next" action since events occurring far apart 
may have no unique order to them (as the discussion in §5.2 indicated). 
Our epistemological interpretation of a transition is not that there really is 
a imique transition which occurs (albeit nondeterministically), but rather 
that any particular order of transitions depends on the frame of reference, 
or the view-point, in which the observations are carried out. This difference 
in the interpretation is perhaps the most significant difference between a 
nondeterministic sequential process and the model of a truly concurrent sys- 
tern: In the nondeterministic sequential process a unique transition in fact 
occurs, while in a concurrent system, many transition paths, represent- 
ing different viewpoints, may be consistent representations of the actual 
evolution. 

Our justification for using a transition system is provided by the work 
of Clinger [81] which showed that one can always define a (non-unique) 
global time to represent the order of events. Events in dinger's work were 
assumed to take infinitesimal time and the combined order of events was 
mapped into a linearly ordered set representing a global time. A global time 
corresponds to events as recorded by some (purely conceptual) observer. 
Remark. Transitions, unlike events, may take a specific finite duration 
and may therefore overlap in time. This is not a problem in actor systems 
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because of the following: 

1. All transitions involve only the acceptance of a communication. 

2. There is arrival order nondeterminism in the order in which com- 
munications sent are accepted and this arbitrary delay subsumes the 
precise duration of a transition. Specifically: 

(a) When a particular communication is sent because of a transition 
need not be explicitly modeled: Although a commimication may 
not have been sent before another transition occurs, this possi- 
bility is accounted for by the fact that the communication may 
not cause the "next" transition. 

(b) When the replacement accepts the next communication targeted 
to the actor is indeterminate: Thus the time it takes to designate 
the replacement need not be explicitly considered. 

(c) The above reasoning holds for creation of new actors as well. 

Global time 7 in any concurrent system is a retrospective construct: it 
may be reconstructed (although not as a unique linear order) after the fact 
by studying the relations on the events in a parallel system. Information 
about the order of events in a circumscribed system is often useful. In 
implementations supporting actor systems, such information is useful in 
delimiting transactions. Transactions are defined by the events affecting 
the reply to a given request (in particular, the events ordered between 



7 By global time, we mean any linear order on the events in the universe. 
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the request and its corresponding reply). Transactions are useful tools for 
debugging a system or allocating resources to sponsor activity. The deter- 
mination of an order of events (the so-called combined order as it combines 
the arrival order with the order of causal activations) in an implementa- 
tion is achieved by running the actor system in a special mode where each 
actor records events occurring at that actor and reconstructing the causal 
activations by following the communications sent. 

The possible ways in which a conceptual observer records events, i.e., the 
behavior of such an observer, corresponds to that of some nondeterministic 
sequential process. This correspondence is the reason why nondeterminism 
is used in mathematical models to capture the parallelism. However, the 
character of the correspondence is representationalistic, not metaphysical. 
In particular, the behavior of a parallel system may be represented by 
many (consistent) nondeterministic sequential processes corresponding to 
different observers. 

5.3.1 Possible Transitions 

In this section, we discuss how actor systems may evolve in terms of their 

descriptions. A transition relation specifies how a configuration may be 

replaced by another which is the result of processing some task in the 

former. 

Notation. Let states and tasks be two functions defined on configurations 

that extract the first and second component of a configuration. Thus the 

range of states is the set of local states functions and the range of tasks is 
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the power set of tasks, where the set of tasks may be treated as functions 
from tags to the target and communication pairs. 

The definition for the possible transition relation essentially shows how 
an interpreter for an actor language would, in theory, work. It thus specifies 
an operational semantics for an abstract actor language. Note that defining 
a language in this manner amounts to specifying its semantics by reduction. 
We will first define the possible transition relation and then show that such 
transitions do indeed exist for any arbitrary configuration. 

Definition 5.8 Possible Transition. Let c^ andc-i be two configurations. 
ci is said to have a possible transition to c 2 by processing a task r = (t, m, k), 
symbolically, 

Cj — ► c 2 

if t 6 tasks(ci), and furthermore, if states(ci)(m) = /? where 

/3{t,m,k) = (T,A,i) 

and the following hold 

tasks(c 2 ) = (tasks(ci) - {r}) U T 

states(c 2 ) - {statesic!) - {(m, /?)}) U A U {7} 

In order to show that there exists a possible transition from some given 
configuration, as a result of processing any given task in that configuration, 
we need to show that a valid configuration can always be specified using 
the above equations for its tasks and states. The proof of this proposition 
uses the conditions on the tags for tasks in a given configuration to assure 
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the functional form for the tasks and states of the configuration resulting 
from the transition. 

Lemma 5.1 If ci and c 2 are configurations such that ci — ^-> ci then no 
task in c 2 has a tag which is the prefix of the tag of any other task in c 2 . 

Proof. (By Contradiction) Let t\ and t 2 he the tags of two tasks Ti and 
r 2 in the configuration c 2 such that t x = t 2 .w for some string of integers w 
separated by periods. We examine the four possible cases of whether each 
of the tasks belongs to the configuration C\. 

If r i> r 2 £ tasks(ci) then since Cj is a valid configuration, we immedi- 
ately have a contradiction. On the other hand, if neither of the two tasks 
are in ci, then by Definition 5.5 the the prefix relation is not valid either. 

We can therefore assume that one of the tasks belongs to the tasks of cj 
and the other does not. Suppose t% € tasks(ci) and r 2 $ tasks(ci). Since 
r 2 ^ tasks(ci), t 2 G T, where T is the set of tasks created in the transition. 
Thus 3i (i 2 = t.i) which together with the hypothesis that t\ = t 2 .w implies 
that ti ~ t.i.w. But since Tj_,t € tasks(ci) we have a contradiction to the 
prefix condition in the tasks of configuration Cj. 

The only remaining case is that of r 2 € tasks(cx) and Tj ^ tasks[ci). 
Now ti = t.i = i 2 .w. If w is an empty string then t is a prefix of t 2 and 
both are elements of tasks(ci), a contradiction. If w — i then t = t 2 and 
thus t 2 ^ tasks(c 2 ). But if to is longer than a single number than Ms a 
prefix of t 2 which also contradicts the condition that they are both tasks in 
Cl . H 
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Lemma 5.2 The set states fa) in the above definition represents a local 
states function. 

Proof. We need to show that the none of the newly created actors have 
the same mail addresses as the actors that already existed in cy. Suppose 
(m',/?') is a newly created actor as a result of processing the task r. If t is 
the tag for the task r then m' = t.i for some nonnegative integer i. Now if 
there is another actor with the same mail address in the configuration C2, 
from lemma 5.2 we know that it can not be a newly created actor. Thus 
it is in the domain of states (ci). Then m' = t.i contradicts the assumption 
that the tags of tasks in C\ are not prefixes to any mail addresses in Cj. H 

Lemma 5.3 The tags of tasks in ci are not prefixes to any mail addresses 
in c-i. 

Proof. Also straightforward (skipped). H 

The above three lemmas imply the following theorem. 

Theorem 5.1 If cy is a configuration and r £ tasks(ci) then there exists 
a configuration ci such that c\ -—> C2. 

5.3.2 Subsequent Transitions 

Of particular interest in actor systems is the fact that all communications 
sent are subsequently delivered. This guarantee of delivery is a particular 
form of fairness, and there are many other forms of fairness, such as fairness 
over arbitrary predicates. We will not go into the merits of the different 
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forms here but will consider the implications of guaranteeing the delivery 
of any particular communication even when there is a possible infinite se- 
quence of transitions which does not involve the delivery of a particular 
communication sent. To deal with this guarantee of mail delivery, it is not 
sufficient to consider the transition relation wc defined in the last section. 
We will instead develop a second kind of transition relation which we call 
the subsequent transition. The subsequent transition relation was developed 
in [Agha 84]. 8 We first define a possibility relation as the transitive closure 
of the possible transition and then use it to define subsequent transition. 

Suppose the "initial" configuration of an actor system had a factorial 
actor and two requests with the n^ and n^ respectively, where n± and n,2 
are some nonnegative integers. Since in this configuration, there are two 
tasks to be processed, there are two possible transitions from it. Thus 
there two possible configurations that can follow "next." Each of these has 
several possible transitions, and so on. This motivates the definition of 
a fundamental relation between configurations which can be used to give 
actors a fixed-point semantics. 9 

Definition 5.9 Possibility Relation. A configuration c is said to pos- 
sibly evolve into a configuration c' , symbolically, c — ►* c' , if there exists 
a sequence of tasks, t\, . . . , t n , and a sequence of configurations, cq, . . . , c n , 



8 Milncr brought to our attention that the relation we define here is similar to that 
developed independently in [Costa and Sterling 84] for a fair Calculus of Communicating 
Systems . 

9 Such a domain does not respect fairness. 
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for some n, a non-negative integer, such that, 

ti t 2 t„ , 

C = Cq > Cx — > • • • — > c n = c 

Remark 1. If n = above, we simply mean the identity relation. 

One could show, by straight forward induction, that the "initial" con- 
figuration, Cf act , with the factorial actor possibly goes to one in which a n! 
communication is sent to the mail address of the customer in the request to 
evaluate the factorial of n. When the factorial actor is sent two requests, to 
evaluate the factorials of the nonnegative integers n* and n.2, one can make 
a stronger statement than the one above: Considering that the computa- 
tion structure is finite, one can show that there is a set of configurations, C 
that Cf act necessarily goes to such that both the factorial of nj and n-i have 
been evaluated. The configurations in C have the interesting property that 
no further evolution is possible from them without communications being 
sent by some external actor. We call such a configuration quiescent (cf. 
termination of a computation). 

Consider the following example which requires concurrent processing of 
two requests. Suppose the factorial actor (as we defined it in Examples 3.2.2 
and 5.2.1) was sent two communications, one of which was to evaluate the 
factorial of — 1 and the other was to evaluate the factorial of n, where n is 
some nonnegative integer. The behavior of the factorial actor implies that 
it would embark on the equivalent of a non-terminating computation. More 
precisely it would send itself a communication with —k in response to a 
communication with —k — 1, and so on, and therefore it will not possibly 
evolve to any configuration which is quiescent. 
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Recall that in the actor model the delivery of all communications sent is 
guaranteed. This implies that despite the continual presence of a commu- 
nication with a negative number in every configuration this configuration 
possibly goes to, it must at some point process the task with the request to 
evaluate the factorial of n. 10 We can express this sort of a result by defining 
the following relation on sets of configurations. 

Definition 5.10 Subsequent Transition Relation. We say a configu- 
ration, c subsequently goes to c' with respect to r , symbolically, c t — * c' , 

if 

(r G tasks(c) A c — ►* c' A r ^ tasks(c') A 

-3c" (r £ tasks(c") A c — +* c" A c" — »* c') 

Basically, the subsequent transition represents the first configuration 
which does not contain the task in question. If we defined the set of con- 
figurations, C, as follows 

C = {c'\ c ^ c'} 

then the guarantee of mail delivery implies that the configuration c must 
pass through C. We can define a necessity relation based on the subsequent 
relation but will not digress here to do so. The subsequent transition thus 
provides a way of defining a fair semantics by derivation for an actor model. 



10 This in turn results in the request to evaluate the factorial of n — 1. Thus by induction 
we can establish that at some point in its life, this factorial actor will (indirectly) 
activate a communication [n!] to the mail address of the customer in the corresponding 
communication. 
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The model is assumed to have these two transition relations as primitives. 

Remark. The subsequent relation defines what may be considered locally 
infinite transitions. This is due to the nature of nondeterminism in the 
actor model. The relation captures the unbounded nondeterminism in- 
herent in the actor paradigm. For a discussion of this phenomenon, see 
[Clinger 81]. Some authors have found unbounded nondeterminism to be 
rather distressing. In particular, it has been claimed that unbounded non- 
determinism could never occur in a real system [Dijkstra 77]. Actually 
unbounded nondeterminism is ubiquitous due to the quantum physical na- 
ture of our universe. For example, it is found in meta-stables states in VLSI 
[Mead and Conway 80]. 



Chapter 6 



Concurrency Issues 



In this chapter, we discuss how the actor model deals with some of the 
common problems in the theory of concurrent systems. The first section 
discusses the implications of the actor model for divergence, deadlock and 
mutual exclusion. The problem of divergence is severely contained by the 
guarantee of delivery of communications. Deadlock, in a strict syntactic 
sense, can not exist in an actor system. In a higher level semantic sense 
of the term, deadlock can occur in a system of actors. Fortunately, even 
in the case of a semantic deadlock, the structure of actor systems implies 
that the "run-time" detection of deadlock, and hence its removal, is quite 
feasible. 

In the second section, we discuss issues related to functionality in a 
system and the imposition of a merge structure on communications. With 
respect to functionality, we show that the concept of side-effect free history 
sensitive functional computation in streams is similar in at least one ab- 
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struct way to the specification of replacement behavior in actors. In both 
cases, history-sensitivity is achieved by similar functional mechanisms. Fi- 
nally, despite the inherent arrival order nondeterminism, we show the abil- 
ity to define communication channels in actors which in effect preserve the 
order of communications between actors. 

6.1 Problems in Distributed Computing 

There are some problems which are peculiar to distributed systems and 
cause one to require a great deal of caution in exploiting distributed com- 
puting. We will discuss three such problems as they relate to actors: 
namely, divergence, deadlock, and mutual exclusion. In each instance, we 
will show how the actor model provides the mechanisms to limit, and per- 
haps to eliminate these problems. 

6.1.1 Divergence 

A divergence corresponds to what is commonly called an "infinite loop." 
In some cases, such as a process corresponding to a clock or an operating 
system, an infinitely extending computation is quite reasonable and termi- 
nation may be incorrect (indeed, aggravating!). At the same time, one may 
wish to have the ability to stop a clock in order to reset it, or bring down an 
operating system gracefully in order to modify it [Hoare 77]. Thus we would 
like to program potentially infinite computations that can nevertheless be 
affected or terminated. 
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If one looked at the computation tree defined by the possibility transi- 
tion then the execution method of an actor program would seem to be mod- 
elled as choice-point nondeterminism [dinger 81] or depth search [Harel 79]. 
In this execution scheme, an arbitrary pending communication is nonde- 
terministically accepted by its target causing a transition to the next level 
in a tree. Using choice-point nondeterminism, it is impossible to guarantee 
the "termination" of a process which has the potential to extend for an 
arbitrarily long period of time. 

Consider the following simple program. We define the behavior of a 
stop-watch to be a perpetual loop which can be reset by sending it an ap- 
propriate communication (an actor with such behavior may even be useful 
as a real stop watch, if we had some additional knowledge about the time 
it took for such an actor to receive and accept the "next" communication 
it sends itself). 

stop-watch(n) 

if message = {go) 

then become new stop-watch(n + 1) 

send (go) to self 
else become new stop-watch(0) 
send [n] to customer 

Suppose x is created with the behavior stop-watch (0). If x is sent a "go" 
message, then x will embark on a nonterminating computation. If we wish 
to "reset" x, we can send it another communication, such as [customer, 
"reset"], where customer is the mail address of some actor. If and when 
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this message is processed, x will be "reset." Without the guarantee of 
delivery of communication, however, the "reset" message may never be 
received by x and there would be no mechanism to (gracefully) reset the 
stop-watch. Since the actor model guarantees delivery of communications, 
x will at some point be "reset." It will subsequently continue to "tick." 




[1] [2] ........ [n] 



Figure 6.1: When a reset message is processed, one of an infinite number 
of messages may be sent to the customer. The stop-watch will subsequently 
continue to tick. 



In the case of the stop-watch the potentially perpetual activity affects 
subsequent behavior. This need not always be the case. A "nontermi- 
nating" computation can sometimes be "infinite chatter." Indeed, this is 
the definition of divergence in [Brookes 83]. We have seen an example of 
this kind of divergence in the case of our factorial actor when it was sent 
a message with —1. In a language where the factorial is defined using a 
looping construct, the factorial could be rendered useless once it accepted 
a message containing —1. This is because it would embark on a nonter- 
minating computation and therefore never exit the loop in order to accept 
the next communication. The nontermination of a computation in a Ian- 
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guage using loops inside a process is a serious problem in the context of 
a distributed system. The process with an infinite loop may be a shared 
resource, as would most processes in a network. Since the process is never 
"done," any other process wishing to communicate with it may not do so 
and one can have a domino effect on the ability of the system to carry out 
other computations. 

One solution to this problem is to use multiple activations of a process. 
In this framework, each communication to the factorial would activate a 
process of its own. Activations solve the problem for unserialized behavior, 
as is the case with the factorial. However, when we are interested in a 
shared object which may actually change its behavior, as is the case in a 
stop-watch, multiple activations are not a solution. 

The actor model deals with the problem of divergence whether or not 
the behavior of actors involved is serialized. Divergence, defined as end- 
less chatter, does not affect other activity in the constructive sense that all 
pending communications are nevertheless eventually processed. The pres- 
ence of such divergence simply degrades the performance of the system. 1 
The guarantee of mail delivery also fruitfully interacts with divergence as 
the term is used in the broader sense of any (potentially) nonterminating 
computation. 



1 Using resource management techniques, one can terminate computations which continue 
beyond allocated time. The actor always has a well-defined behavior and would be 
available for other transactions even if some concurrently executing transactions run 
out of resources. 
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6.1.2 Deadlock 

One of the classic problems in concurrent systems which involve resource 
sh«aring is that of deadlock. A deadlock or deadly embrace results in a 
situation where no further evolution is possible. A classic scenario for 
a deadlock is as follows. Each process uses a shared resource which it 
will not yield until another resource it needs is also available. The other 
resource, however, is similarly locked up by another process. An example 
of the deadlock problem is the dining philosophers problem [Dijkstra 71]. 
The problem may be described as follows. Five independent philosophers 
alternately eat and philosophize. They share a common round table on 
which each of them has a fixed place. In order to eat, each philosopher 
requires two chopsticks. 2 A philosopher shares the chopstick to his right 
with the neighbor to the right and like-wise for the chopstick to his left. It 
is possible for all the philosophers to enter, pick up their right chopsticks 
and attempt to pick up the left. In this case, none of the philosophers can 
eat because there are no free chopsticks. 

The behavior of a philosopher and that of a chopstick is described as 
follows: 3 



2 The usual version is two forks. However, it has never been clear to me why anyone, 
even a philosopher, would require two forks to eat! 

3 Since we are using expressions, if we were in SAL or Act, we would have to specify the 
behavior in case the reply from the chopstick was not free. However, the problem of 
deadlock has been formulated with no defined behavior in such cases. 
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Figure 6.2: The scenario for the Dining Philosphers problem. Shared re- 
sources can lead to deadlock in systems using synchronous communication. 



phil ( left-chop , right-chop) { ] 
let x = call right-chop [ pick ] 
and y = call left- chop [ pick } 

{ if x = free and y = free then (eat) . . . } 

chopstick(state) [k] 

if k = pick and if state = "free" 
then reply [free] 

become new chopstick (busy) 



A solution to this problem is to define a waiter who acts as a recep- 
tionist to the dining area: The waiter can make sure that no more than 
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four philosophers attempt to eat simultaneously. In this case, at least one 
philosopher will be able to pick up two chopsticks and proceed to eat. Sub- 
sequently, this philosopher would relinquish his chopstick allowing another 
philosopher to eat [Brookes 83]. 

The "waiter" solution is a particular example of the strategy of access 
to a shared resource in order to avoid the possibility of deadlock. The 
difficulty with this solution is that the mechanisms for avoiding deadlock 
have to be tailored using advance knowledge about how the system might 
deadlock. Furthermore, the waiter is a bottleneck which may drastically 
reduce the throughput in a large system. However, this is the only sort 
of solution in systems relying on synchronously communicating sequential 
processes. In fact the philosopher who picks up his right chopstick can not 
communicate with his left chopstick as the left chopstick is "busy" with the 
philosopher to that chopstick's left. Furthermore, even if a philosopher, 
phili, knew that he shared his left chopstick with another philosopher, say 
phili, unless phili was already ready to communicate with phil u the latter 
could not send a message to the former. In such a system, not only is 
there a deadlock, but there is no mechanism for detecting one. In fact in 
languages using synchronous communication, deadlock has been defined as 
a condition where no process is capable of communicating with another 
[Brookes 83]. 

Two areas of Computer Science where the problem of deadlock arises in 
practice are operating systems and database systems. In operating systems, 
deadlock avoidance protocols are often used. However, in database systems 
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it has been found that deadlock avoidance is unrealistic [Date 83]. The 
reasons why deadlock avoidance is not feasible in concurrent databases can 
be summarized as follows: 

• The set of lockable objects (cf. chopsticks in the dining philosophers 
example) is very large — possibly in the millions. 

• The set of lockable objects varies dynamically as new objects are 
"continually created. 

• The particular objects needed for a transaction (cf. "eating" in our 
example) must be determined dynamically; i.e., the objects can be 
known only as the transaction proceeds. 

The above considerations are equally applicable to the large-scale con- 
currency inherent in actor systems. The actor actor model addresses this 
problem in two ways. First, there is no syntactic (or low-level) deadlock 
possible in any actor system, in the sense of it being impossible to com- 
municate (as in the Brookes' definition above). The chopstick, even when 
"in use," must designate a replacement and that replacement can reply to 
the philosopher's query. What sort of information is contained in the reply, 
and what the philosopher chooses to do with the reply depends on the pro- 
gram. If each philosopher is programmed to simply keep trying to use the 
chopstick then, indeed, in a semantic sense, the system can be deadlocked. 
However, notice that one can specify the behavior of the chopstick so that 
the replacement replies with information about who is using it even while 
it is "busy." Thus, phili can query phili about phi^s use of the chopstick 
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shared between them. In the end, it would be apparent to the inquisitive 
philosopher that he was waiting for himself — which is the condition for 
deadlock. 

The most involved aspect of a deadlock is detecting it. Since in the 
actor model, every actor must specify a replacement, and mail addresses 
may be communicated, it is possible to detect deadlock. An actor is free 
and able to figure out a deadlock situation by querying other actors as to 
their local states. Thus an actor need not be prescient about the behavior 
of another actor. For example, the ability to communicate mail addresses 
means that a philosopher need not know in advance which other philosopher 
or philosophers may be using the chopstick of interest. These philosophers, 
while they may be "busy" eating or looking for a chopstick, nevertheless 
are in turn guaranteed to accept communications sent to them, and thus a 
system can continue to evolve. 

Our solution is in line with that proposed for concurrent database sys- 
tems where "wait-for" graphs are constructed and any cycles detected in 
the graphs are removed [King and Collmeyer 73]. We would carry out the 
process of breaking the deadlock in a completely distributed fashion. A 
concern about deadlock detection is the cost of removing deadlocks. Expe- 
rience with concurrent databases suggests that deadlocks in large systems 
occur very infrequently [Gray 1980] . The cost of removing deadlocks is thus 
likely to be much lower than the cost of any attempt to avoid them. 

A system of actors is best thought of as a community [Hewitt and 
de Jong 83]. Message-passing viewed in this manner provides a founda- 



CHAPTER 6. CONCURRENCY ISSUES 137 

tion for reasoning in open, evolving systems. Deadlock detection is one 
particular application of using message-passing for reasoning in an actor 
system: Any actor programmed to be sufficiently clever can figure out why 
the resource it needs is unavailable, and without remedial action, about 
to stay that way. To solve this sort of a problem, negotiation between in- 
dependent agents becomes important. In open and evolving systems, new 
situations will arise and thus the importance of this kind of flexibility is 
enormous. 

Another consequence of "reasoning" actors is that systems can be easily 
programmed to learn: A philosopher may become one that has learned to 
query some particular philosopher who is a frequent user of the chopstick 
it needs instead of first querying the chopstick. Or the actor may become 
one which avoids eating at certain times by first querying a clock. 

6.1.3 Mutual Exclusion 

The mutual exclusion problem arises when two processes should never si- 
multaneously access a shared resource. An actor represents total contain- 
ment, and can be "accessed" only by sending it a communication. Fur- 
thermore, an actor accepts only a single communication and specifies a : 
replacement which will accept the next communication in its mail queue. 
The actor may specify a replacement which simply buffers the communi- 
cations received until the resource is free. We have seen an example of 
this strategy with insensitive actors. Although, a single receptionist may 
control access to a resource, the resource itself can still be modelled as a 
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system of actors so that there may be concurrency in the use of the re- 
source. There can also be multiple receptionists in a system, when this is 
appropriate. The mutual exclusion problem, it can be safely asserted, is 
not really a problem for actors. 

6.2 Graphic Representations 

In this section, we deal with some of the graphical aspects of the communi- 
cation patterns. First, we disciiss the analogy between the ability to send 
oneself communications in dataflow and the replacement model in actors. 
We establish the functionality in the behavior of actors by defining nodes 
in the spirit of dataflow graphs to illustrate the similarity. Second, we treat 
the problem of communication channels and the ability, in actors, to con- 
strain the effects of universal nondeterministic merges without defining any 
new construct. 

6.2.1 Streams 

A stream is a sequence of values passing through a graph link in the course of 
a dataflow computation [Weng 75]. Streams were introduced for 'side-effect 
free history- sensitive computation'. In this section, we show by analogy to 
streams, that actors are also side-effect free in the same sense of the term. 
To see the equivalence, consider each node as containing a single behavior 
definition which is equivalent to all the behavior definitions which may be 
used by the replacements. The fact that there may be a sequence of def- 
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initions in a SAL program is a matter expressive convenience. Actually, 
having more than one behavior definition does not really change anything. 
The identifier used in a new expression is simply a selector of which behav- 
ior definition to use and this fact can be communicated just as well. There 
are only a finite number of definitions, and the identifier corresponding to 
each one is simply a selector. A single behavior definition which receives 
an identifier and branches on it to the code corresponding to the behavior 
would have an equivalent effect. The become command in the program is 
equivalent to sending oneself a communication with the values of acquain- 
tances including the identifier corresponding to the definition to be used in 
order to determine the replacement behavior. 

There is an apparent difference between actors and nodes in dataflow 
graphs; in dataflow the values "output" form a single stream. So the corre- 
spondence can be visualized more closely using the picture Fig. 6.3 which 
uses appropriate filters on the stream to separate the message intended for 
the actor itself and that intended for "output." 

Of course actors, unlike the elements of dataflow, do more than pass 
streams — they may change their acquaintances and they may create other 
actors. Furthermore, actors themselves are not sequential in character and 
the replacement is concurrently executed. One consequence of this is the 
ability to use recursive control structrures which can not be used in static 
dataflow. One variation of the dataflow model allows for fully re-entrant 
code by tagging the "tokens" (messages) [Gurd et al 85]. This, however, 
results in forcing the computation through a possible bottleneck instead of 
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Figure 6.3: The replacement of an actor can be computed using streams 
which feed the value of the requisite identifiers for the new behavior. Actors 
can separate the values needed for replacement from those "output. " 

distributing it as is conceptually feasible. The cause of this limitation is 
the static nature of inter-node topology. Although the actor model allows 
for dynamic creation, the behavior of an actor is nevertheless functionally 
determined. 



6.2.2 Message Channels 

Many systems preserve the order of messages between processes. A stream 
in dataflow is defined as a sequence of values, and thus by definition is 
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ordered. This creates the interesting problem in dataflow when the order 
of input from two sources can not be pre-determined. A special element for 
non-deterministic merge has to be assumed and such an element can not 
be defined in terms of the other constructs in the dataflow model. 

The preservation of the order of messages between processes is some- 
times simply a function of the hardware configuration. For example, in 
point-to-point communication between two processors the message chan- 
nel preserves the order of communications. Sometimes this property can 
be usefully exploited in computations. An example of this kind of use is 
found in [Seitz 85] which describes as architecture based on 64 processors, 
called the Cosmic Cube. In Seitz's system, multiple processes may reside 
on a single processor but processes are never migrated. The processes are 
asynchronous and use message-passing to interact. However, unlike actors 
the messages are sent along fixed channels so that (coupled with the lack 
of migration of processes) the order in which messages are sent by a pro- 
cess A to a process B is the same order in which B receives those messages 
(although other messages may be inter-leaved). 

There are two problems with the strong hardware-based order preserva- 
tion of message. First, the failure of a single processor would be disastrous 
since one couldn't re-route a message and necessarily preserve its order in 
transmission with respect to other messages already sent. Secondly, this 
scheme creates difficulties in load balancing which requires variable routing 
of messages and migration of processes. It is for these reasons that the 
actor model assumes nondeterminism in the relation between the order in 
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Figure 6.4: A communication channel preserves the order of communica- 
tions between two processes. Such channels can be readily defined in actor 
systems. 

which communications are sent and the order in which they are received. 
Such nondeterminism is termed arrival order nondeterminism. 

It is nevertheless possible to define actors which preserve the order in 
which they, in effect, process communications from each other. Suppose 
we wished that an actor / "processed" communications from an actor g in 
the same order as they were sent by g. What the actor g needs to do is 
tag each message it sends to / with a reference number and increment that 
number each time. The actor / in turn remembers the number of messages 
it has so far processed from g. If it has processed two, and message number 
4 from g arrives next, / simply buffers that communication until it has 
accepted message number 3 from g. Since the delivery of communications 
is guaranteed, the communication enclosing message number 8 will also 
arrive. Subsequently, the actor / will check its buffer for message number 
4 and proceed to process the same. The details can be easily written out 



CHAPTER 6. CONCURRENCY ISSUES 143 

in SAL. We have shown that it is not necessary to add any new constructs 
in order to define order-preserving communication channels in an actor 
language. 

The scheme we use to show the definability of channels is similar to 
that used in Computer Network Architectures where sequence numbers are 
used in packet switched networks to carry out sequence checking [Meijer 
and Peeters 83]. However, unlike network architectures, we do not make 
ubiquitous use of virtual network channels because doing so would generally 
have the effect of slowing the speed with which parallel computations were 
actually carried out. 



Chapter 7 

Abstraction And 
Compositionality 



The ability to write and debug large software systems is strongly depen- 
dent upon how successfully the system can be partitioned into independent 
modules. Two modules are independent if we can ignore the internal details 
and treat them as black-boxes with certain input-output behavior. Concur- 
rency involves a nondeterministic interleaving of events; one consequence of 
such interleaving is that when systems are composed, events in one system 
are interleaved with the events of the other. Unfortunately, the behavior of 
the composed system is not necessarily deducible from the abstract repre- 
sentations of the behaviors of the modules composed. In this chapter, we 
address these issues as they relate to concurrency in general and our actor 
language in particular. 
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7.1 Abstraction 

A classic problem in concurrent systems is the difficulty abstracting away 
from the operational behavior of a system. Consider a programming lan- 
gtiage with the assignment command. Let 7 be the function which maps 
commands in this programming language to their meanings. Let S\_ == x :— 
x + 1 be a command in this language. If n is any given integer, the state 
a jn/x| stands for a state where n is the value of x. Now the meaning of Si 
can be expressed as: 

7(Si): a[nfx\ — -> a\n + 1/x] 

Similarly, if S 2 = x '•— 2 * x then the meaning of S 2 is given by 

7(S 2 ) : <r\n/x\ — > a|2 * rt/sj 

If we were to compose the commands 5i and S2 sequentially, then their 
meaning functions would also be composed sequentially. However, if we 
are going to compose the two commands concurrently then the situation 
is not so simple. Suppose that the command S represents the concurrent 
composition of the Si and £>2, i^., S = Si || S2, where || represents con- 
current composition. The meaning of S is not obvious: If we started in 
a state where x = 2, then two of the possibilities are that Si precedes 
52 or the other way round. In each case, we can deduce the meaning of 
S by sequentially composing the meanings of Sj and S2: Thus after the 
execution of both commands, x may be 6 or it may be 5. However, it is 
also possible that the execution overlaps in time. For example, to execute 
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Si we may FETCH the value of x, but before S% has finished execution, x 
may be fetched by S2 ■ In this case, the "final" state could be a|3/xj or 
cr[4/x], neither of which is obvious from a composition of the denotational 
meanings of the two commands. 1 

7.1.1 Atomicity 

The solution to this problem is usually given by specifying which commands 
are atomic, i.e., by specifying that the execution of certain commands may 
not be interrupted [de Bakker 80]. For example, if the assignment com- 
mand is defined to be "atomic," then one would need to interleave only the 
meanings of assignment commands. 

The problem with the atomicity solution is that it fixes the level of 
granularity or detail which must be retained by the meaning function. Thus, 
if the assignment command is atomic, one must retain information about 
each and every transformation caused by an assignment in a program. This 
necessarily means that one can not abstract away the operational details 
to any higher degree. If, for example, one is defining the abstract meaning 
of an iterative loop, all the transitions involved in the iterative loop must 
be retained by the meaning function. 

The approach to abstraction in actor systems is somewhat different. 
*It may appear that 

?(Si || S») = M{S i; S 2 ) U T(S a ;Si) U 7(Si) u 7(5 2 ) 

but one can construct a slightly more complex example where this relation does not 
hold either. 
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The concept of a receptionist is defined to limit the interface of a system to 
the outside. The use of the receptionist concept is illustrated in the context 
of the assignment example. We define two systems whose behavior differs 
partly because the receptionist in each is used to attain a different level of 
abstraction. Consider the first system: x is the receptionist in this system 
and the behavior of x is as follows: 

x(n) [(request)] 

if (request) = FETCH then reply [n] 

if (request) — STORE i then become new x{i) 

This system has the a level of granularity where the behavior of the con- 
figuration must be considered in terms of interleaving FETCH and STORE 
messages. However, in a larger system x may no longer be a receptionist 
and it may be possible to avoid this level of detail. For example, let r be the 
receptionist for an actor system and the behavior of r be given as follows: 

r ( n ) [(request)] 

if (request is to assign value f(x)) 

then let a=f(n) { become new r(a) } 
if (request is to show value) 

then reply [n] 

Note that the nesting of the become command inside the let expression 
creates a sequentiality in the execution (see the discussion about the let 
construct in §4.3). In this larger configuration, one need no longer consider 
the FETCH or STORE events. The level of granularity is comparable to the 
"atomicity" of assignment commands. However, we can define yet larger 
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systems with other receptionists so that these operational details can be 
ignored as well. We illustrate this concept by means of another example. 

7.1.2 Nesting Transactions 

Consider a bank account which may be accessed through different money 
machines. Suppose further that this bank account is shared between several 
users. The behavior for such a bank account may be something like that in 
Example 3.3. Now one may want that once the account is accessed through 
a money machine, it should complete the transactions with the user at that 
machine before accepting requests for transactions from other users. The 
definition of the bank account as given in example 3.3 implies that the bank 
account processes one request at a time but that it may interleave requests 
from different "users" and "money machines." To create a system where 
transactions at each money machine are completed before other transac- 
tions are acceptable, we define a larger configuration where the receptionist 
for the system is some actor called account-receptionist. All communica- 
tions to the account must be sent through this receptionist and the trans- 
actions of the account-receptionist consist of several sub- transactions with 
the users. The behavior of the receptionist may be described as follows: 
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a-free-account 

become (a-busy- account with the current customer) 
(process the request) 

a-busy- account 

if customer / (current customer) 
then send (request) to buffer 
if customer = (current customer) 
then if (request = release) 

then send (release) to buffer 

become a-free-account 
else (process the request) 

What the receptionist does is to prevent the interleaving of requests 
to the account from different users. An analysis of the behavior of this 
system can thus be done by considering the overall results of transactions 
from each machine without having to consider all the possible orders in 
which the requests from different machines may be recieved. We need to 
consider the possible order in which entire sets of sub- transactions may 
occur (since the order in which the first request from a user is received is 
still indeterminate). 

One can construct arbitrarily complex systems so that their behavior 
is increasingly abstract. There is no pre- determined level of "atomicity" 
for all actor systems. Instead, it is the programmer who determines the 
degree of abstraction; the concept of receptionists is simply a mechanism 
to permit greater modularity and hence procedural and data abstraction. 
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7.2 Compositionality 

One of the desirable features about Milner's Calculus of Communicating 
Systems (CCS) is that it models compositionality rather effectively. Mil- 
ner's notion of composition is based on mutual experimentation by two 
machines: a machine S offers experiments which may combine with exper- 
iments of another machine T to yield an "interaction." Both machines, 
as a result of the interaction, change their local states. Milner's notion of 
interaction is based on intuitions of how machines may be plugged together 
physically, a notion that relates very well to synchronous communication. 





n 










p 


a 




< 



i>y 



Figure 7.1: Synchronous composition: In CCS, composition of systems is 
analogous to plugging machines together. Figure from [Milner 80]. 



When an interaction between two machines occurs in Milner's system, 
one simply links the ports on the two machines. Ports which may be linked 
are considered complimentary ports. One can hide a port provided one also 
hides its complement. Thus, upon composition, one can abstract away from 
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the ports by an operation called restriction. 

7.2.1 Actors and Ports 

The notion of hiding ports using the restriction operator has somewhat 
different implications in CCS than its intuitive interpretation seems to be 
when thinking in terms of actors. When a port and its complement have 
been restricted, its the interaction between the two that has been hidden. 
The port as a result of the interaction, will subsequently unfold its behavior 
and this behavior will not be hidden. Thus, to use actor jargon, the port 
may "become" another port which may even have the same label as the 
one that is hidden. In terms of actors, the restriction operator is equivalent 
to hiding the acceptance of a single communication; it is not equivalent to 
hiding all the communications that may be received by the given actor. 

A system of actors is best thought of as a community of agents. The 
agents retain their identity even as their behavior changes. Actors have 
mail addresses which permanently identify them. The "behavior objects" 
in CCS do not necessarily maintain any "identity" as they interact with 
the other objects. For example, in CCS, once an agent accepts an input, it 
may never accept another input on the same port, as it may no longer have 
the same port as a result of processing the communication. Besides, the 
ports do not uniquely identify an agent since different agents may use the 
same "port" name and thus different complimentary ports may be linked. 
In contrast, communications in actors are sent to a specific unique target 
actors. 
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There are other differences between the behavior of an agent in CCS 
and that of an actor. One of these is that agents in CCS are themselves 
sequential in character: only one experiment may be performed at a time. 
The justifications Milner provides for this sequentially are: 

1. Tractability of the model; and, 

2. The desire to have a "behavior object" represent the system according 
to an observer capable of only one experiment at a time. 

We gave a similar argument about the import of using nondeterminism 
to model concurrency (§5.2). The fact remains that concurrency includes 
the potential for overlap in time in both models. There is, however, a fun- 
damental difference between Milner's "behavior objects" and the behavior 
of an actor: the actor itself is a concurrent agent. The difference is reflected 
in the language defined by Milner to illustrate CCS and actor languages: 
in the former, sequentiality is intrinsic; in the latter, it is present only due 
to causal interactions (§4.2). 

7.2.2 Encapsulation in Actors 

Any system must have receptionists which can accept information from the 
"outside," and any system must know of agents that are external to the 
system. The designation of receptionists and external actors provides for 
structuring the input-output behavior (or, what in other fields would be 
called the stimulus-response or sensori-motor aspects) of a system. There 
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are several observations to be made here which are relevant to actor sys- 
tems: 




Figure 7.2: Communications sent by p% to r<i are not observable in an en- 
capsulated system, just as those sent by r t to pi are "internal. " 



An actor which serves as a receptionist may also be known to other 
actors within the system. Communications between such "internal" 
actors and a receptionist will not be observable. Thus it is not so much 
an actor that is visible or hidden, but rather it is communications 
between a given sender-target pair that are observable when either 
the sender or the target is external. (See Fig. 7.2.) 

As a system evolves, new receptionists may be added and new external 
actors may become known. The mechanism for this change is simply 
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the ability to send messages containing mail addresses. 

• One can no t arbitrarily restrict receptionists: Once a mail address has 
been communicated to the outside, it is available for use by external 
actors. However, if a mail address is unknown to the outside, or 
becomes unknown, then the actor is no longer a receptionist. 

7.2.3 Composition Using Message-Passing 

Compositionality in actors is achieved by message-passing. Independent 
systems are connected by sending some external actors in each module a 
communication to become forwarding actors which simply send their mail 
to some receptionists in the other module. The justification for the term 
"become" in the specification of replacement actors is the same as the 
reason why the external actors and receptionists they forward their mail to 
are equivalent. We observe the following: 

Proposition: If the behavior of an actor x is unserialized, and its behavior 
is to forward all the communications it accepts to an actor y, then sending 
a communication to x is equivalent to sending the communication to y. 

The proposition is seen to be true because of the arrival order nonde- 
terminism in the actor model. A communication sent to the actor x will 
be eventually recieved by the actor y. Since the arrival of a communica- 
tion is always subject to an arbitrarily delay, even if the communication 
was originally targetted to y, it would have arrived at some indeterminate 
time at y. Note that the guarantee of delivery is essential in establishing 
this proposition because otherwise it would be possible for x to recieve the 
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communication and yet y to never receive it. 

The rigorous proof of the above proposition would require us to show 
that given a configuration with a forwarding actor, we can construct an 
equivalent configuration without the forwarding actor replacing the actor's 
mail address in the acquaintance lists of all actors and tasks in the config- 
uration defined with the mail address of the actor to which it forwards the 
communications it receives. The two configurations must be shown to be 
equivalent in some semantic sense. When an actor, x, acquires the unseri- 
alized behavior to forward all communications it receives to an actor y, the 
actor x is said to become y. Using the above proposition as justification we 
will assume that two such actors are one and the same. 

The rules to compose configurations are developed and these may be 
used to compose systems by composing configurations they may be in. All 
composition will be done using message-passing, and as a consequence there 
is no need to assume uniqueness in the configuration at the "time" of com- 
position of a system: The impact of the composition is nondeterministic 
because of the arrival order nondeterminism in the communications which 
are forwarded. Since there is arrival order nondeterminism for all mes- 
sages in actors, no special construction is necessary to the represent the 
composition of two systems. 

7.2.4 Rules for Composition 

In this section we develop the constraints that must be satisfied by any 
scheme which carries out the composition of two systems. We provide 
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the constraints in terms of configurations and assert their realizahility by 
showing a definition of composition which would satisfy the conditions. To 
compose actor programs, one would map them to the initial configurations 
they define and compose these configurations using the rules of composition 
given. 

Constraints on Interface Actors 

We first define all the applicable rules for constraining the actors that in- 
terface with the outside — i.e., set of receptionists and external actors for 
a composed system. 

Let external) represent the actors which are external to a configuration 
Ci, and recep(c2) represents actors which serve as receptionists in some 
configuration c^, then there may be some actor x such that x G extern(ci)n 
recepfa). It is also possible (but not necessary) that when C\ and Ci are 
composed, such an actor x is no longer a receptionist of the composed 
system because the only actors x may have been a receptionist for are in 
the other system composed. In any case, x will not be external to the 
composed system. Let c = c± || C2, where || represents the composition 
operator. We can assert the following properties about the receptionists 
and external actors of c: 

1. All receptionists in the composed system must be receptionists in one 
of the two configurations: 

recep(c) C recep(ci) U recep(c2) 



CHAPTER 7. ABSTRACTION AND COMPOSITION ALITY 157 

2. The only actors which may no longer be the receptionists are actors 
that are external to one of the configurations composed: 

(recep(ci) U recepfa)) — recep(c) C external) U exlem{c-i) 

3. All external actors in a composed configuration must be external to 
one of the two configurations: 

extern(c) C external) U externfa) 

4. The only actors which may no longer be external are actors that are 
receptionists for one of the configurations composed: 

(extern(cjt) U extern(c 2 )) — extern(c) C recep(ci) U recepfa) 

Since we wish to have the identifiers in an actor program (and corre- 
spondingly mail addresses in a configuration) be local to the module (or 
to the configuration), we have to provide a means of "relabeling" the same 
so as to link receptionists and external actors. Thus when two program 
modules are composed, we may have a declaration of the form: 

let idi = idi and id$ — id± . . . 

where idi is the identifier for an external actor in the first module, and id^ 
is an identifier for a receptionist in the second, or vice-versa. Similarly for 
id s and id 4 , and so on. The intended interpretation of the above declaration 
is that in order to compose two modules, we simply send an appropriate 
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communication the external actors in each of the modules telling them 
which receptionist in the other module they should become. 

One can not necessarily deduce the receptionists of a composed system 
from the receptionists of its constituents: Some receptionists may have been 
so designated only because they were supposed to represent external actors 
in the 'other' module. Thus a new receptionist declaration may be given 
for a composed system, provided that such a declaration satisfies properties 
1 and 2 above. 

Formalizing Composition 

We now turn to developing a detailed definition for composing two config- 
urations. To be precise, assume a configuration is a four tuple with the 
functions states, tasks, recep, and extern extracting each component. (We 
are expanding the definition of a configuration used in chapter 5 which was 
concerned more specifically with the internal evolution of an actor system 
and thus took into account only the first two components.) The population 
of a configuration c, pop(c), consists of mail addresses that are in c but are 
not elements of extern(c). Suppose c^ and c^ are two configurations. To 
compose Ci and C2, we need to specify the new receptionists and external 
actors. Notice that if c t and c<i are arbitrary configurations and we assume 
mail addresses are local to a configuration (recall that mail addresses are 
merely ways of labeling actors to specify topological properties of a sys- 
tem), then there is no guarantee that pop(ci) n pop(c2) = 0. Similarly, 
if iags(c) is the set of tags used in the tasks(c), then it is possible that 
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tags(ci) PI tagsfa) ^ 0. 

In fact, even if the populations and tags of two configurations are dis- 
joint, the states and the tasks can not be simply combined using the union 
operation. To see why, recall the prefix condition in the definition of a 
configuration (Definition 5.3) and its use in Theorem 5.1: The condition 
states that no tag be the prefix of any other tag or mail address in a con- 
figuration. This property is necessary to maintaining the uniqueness of all 
tags and mail addresses of tasks created. 

Tags and mail addresses have no reality of their own. They are merely 
labels we define to keep a track of computation in an actor system. So we 
will provide a map to new tags and mail addresses in a composed system 
so that the new tags maintain the structure implied by the original tags 
and at the same time satisfy the requisite constraints. Providing a map to 
carry out the composition has no intrinsic value but simply demonstrates 
the ability to carry out composition. 

Definition 7.1 Composition. Suppose that c, cj and c<i are configura- 
tions such that c = ci \\d,h c 2, where D is a declaration equating external 
actors and receptionists, and R is a receptionist declaration satisfying the 
constraints given above. Let the declarations in D be equivalences of the 
form i.e th j.r where i, j G {1,2}, e G extern(ci) and r G recep(cj). 
Then the following conditions hold: 

1. The tags and mail address are simply prefixed by the configuration 
they came from. Thus, 

tasks(c) — {(i.t,i.m,k') \ (t,m,k) G tasks(ci) A A' = k\i.t/t, . . .J} 



states (c)(i.m) — < 
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2. The states of all actors not in the declaration D are unchanged ex- 
cept of the transformation on the mail addresses. Let forwarding (x) 
represent the behavior of an actor which sends all communications it 
accepts or has buffered on to x, then 

forwarding(j.r) if i.m « j.r in D 

b otherwise given (m, 6) £ c,- 

3. The external actors are those who have not been declared to be equiv- 
alent to some receptionist in the composed system. 

extern(c) = (eifern(ci) — {x \ 3r G recep(c 2 )(l.x = 2.r e D)} U 
(extern^) — {x | 3r 6 r-ecep(c 2 )(2.a: = l.r € D)}) 

4- The receptionists of c are given by the declaration R. 

Note that our definition can be easily extended to composition of an 
arbitrary number of configurations. Parallel composition should of course 
be commutative and associative. In our definition, the configurations them- 
selves would be different depending on the order of composition. However, 
there is a strong equivalence relation between them, namely a direct rela- 
beling equivalence. Since there are only a finite number of tags and mail 
addresses the problem of determining the equivalence of any two configu- 
rations is decidable. 

To compose already existing systems, we need to compose all the con- 
figurations the systems may be in. If we use the c x + c 2 to represent the 
fact that a system may be in configuration c\ or in configuration c 2 then: 

(ci + c 2 ) || (c 3 + c 4 ) = (c x || C 3 ) + (Cj || c 4 ) + (c 2 || c 3 ) + (c 2 || c 4 ) 
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where any declarations in the composition on the left hand side of the 
equation are carried out to each of the terms in the right hand side. 

7.3 The Brock- Ackerman Anomaly 

An algebra of concurrent processes is defined over equivalence classes of 
the processes. 2 The canonical members of each equivalence class provide 
an abstract representation for all the processes in the class. There are two 
considerations in defining equivalence relations. On the one hand, the ab- 
stract representation of processes must discriminate between systems which 
when operated on or composed with other systems lead to behaviors we 
wish to distinguish from each other. On the other hand, the representa- 
tion must not discriminate between systems that behave identically in all 
contexts. A context is determined by the degree of encapsulation and the 
"environment" of other processes it interacts with. 

In the case of sequential programs, the history relation which maps in- 
puts to outputs is sufficient to provide an abstract characterization of a 
program. In the context of concurrent systems, the history relation is the 
weakest equivalence relation which may be used to model systems. In other 
words, it contains the minimal information necessary to differentiate be- 
tween systems. Unfortunately, as [Keller 77] and [Brock and Ackerman 81] 
have shown, it is not sufficient to discriminate between systems that are 
observably different. Of the two cases cited, the Brock-Ackerman anomaly 
2 In this section we use the term process to impart a general flavor to the discussion. In 
particular, systems of actors are "processes." 
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represents a more serious problem. We discuss it in the context of actor 
systems. 

The Brock-Ackerman anomaly shows that when each of two systems 
with the same history relations is composed with an identical system, the 
two resulting combined systems have distinct history relations. Let )/ be a 
function mapping a process to the history relation it defines. We convert 
the relation into a function by using the standard technique of collecting all 
the terms representing the possible elements which are related to each given 
element of the domain. We first define two actor systems Si and <S 2 such 
that they have an H(Si) = X(S 2 ). We then define a system U and show 
that M(Si || U) 7^ )i(S2 || U) where || represents a parallel composition. 

The receptionist in both systems Si and S% is an actor whose behavior 
is described by: 

D(a) [k] 

send [k] to Pj 
send [k] to P,- 

In other words D accepts a communication and sends two copies of it to 
an acquaintance a. Its behavior is unserialized. The external actor in 
both systems Si and S2 is called extern-acq. In Si the behavior of the 
acquaintance a is to store the first communication it accepts and to send it 
and the second communication accepted to extern-acq. It can be described 
as : 
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Pi(inputs-so-far, external-acq, first-input) [k] 

if inputs-so-far— then become new Pi(l, external-acq, k) 
if inputs- so- far=l then 

become SINK 

send [first-input] to external-acq 

send [k] to external-acq 

where the behavior of a SINK is simply to "burn" all communications it 
accepts. 

Now a system whose population is {d,p}, with behaviors Z?(pi) and 
Pi(0,e, 0), respectively, and whose external actor is e, has the history rela- 
tion which maps: 

-> 

{zi} ■-♦ hi Vi) 
{xi i 2 } -> {yi yi , yi y 2 , y 2 y2> 

where x t is the communication A;, sent to the target d, and y, is the com- 
munication ki sent to the target e. Recall the arrival order nondeterminism 
in actors. Thus x± i 2 is the same as i 2 x± since the communications may 
arrive in either order at the target d. Internally, when d accepts [ki] it will 
send two ki messages to pi and similarly for fc 2 . However, these four com- 
munications to pi may be interleaved in an arbitrary manner. In general, 
the history relation can be represented as: 

xi ... z„-> {xi x 3 ■ | 1 < i,j < n} 

Now consider an actor system 5 2 with a receptionist d which has an ac- 
quaintance p 2 . The initial behavior of p 2 is described by P 2 (0,e) where: 
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P2(inputs-so-far, external-acq) [k] 
send [k] to external-acq 

if inputs-so-far- then become new Pi(l, external-acq) 
if inputs-so-far— 1 then become SINK 

The difference between the (initial) behavior of px and pi is that px waits 
for two inputs before forwarding them both but p 2 forwards two inputs as 
they are received. However, as the reader may readily convince themselves, 
because of arrival order nondeterminism the history relation on the system 
Si is identical to that on system Sx. 

Suppose that each of the actor systems Si are composed with another 
actor system U where ex is the receptionist and has the (unserialized) be- 
havior Z£(ei,e 2 ), where E is as follows: 

E(external-acql , external- acq2) [k] 
send [k] to external-acq2 
send [k] to external- acql 
send [5 * k] to external- acql 

In U both ex and e 2 are external. When we compose Sj with U, d is the 
only receptionist and e% the only external actor in the composed system. 
The external actor a in U is declared to be the receptionist d (see fig 7.3). 
The history relation on Tx which is the composition of Si and U maps 

xir-* Vx Vi 

where yx is the message kx to e 2 . Note that px has accepted both commu- 
nications before forwarding them to e 2 . However, the history relation on T2 
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Figure 7.3: The Brock- Ackcrman anomaly. When the systems Si and S2 are 
composed with a system U which has the population ty, the history relations 
of the two composed systems are quite different. 



maps 

xi-* {vi Vi , Vi y[} 

where y[ is the message 5*&i sent to e%- This happens because the second k\ 
sent to p 2 niay arrive after the 5 * k± message sent by ex has been forwarded 
and accepted by p\. 

The Brock-Ackerman anomaly demonstrates the insufficiency of the his- 
tory relation in representing the behavior of actor systems (in fact, in any 
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processes which have a nondeterministic merge in them). The problem 
with the history relation is that it ignores the open, interactive nature of 
systems which may accept communications from the outside and send com- 
munications out at any stage. Having sent a communication, the system 
is in a different set of possible configurations than it was before it did so, 
and provided we have a model for the behavior of a system, we can deduce 
that the number of possible configurations it may be in has been reduced. 
Thus the two systems, Si, and 52 are different to begin with because after 
having sent a communication to the outside, their response to subsequent 
communications from the outside is distinct. 

7.4 Observation Equivalence 

We have seen two equivalence relations on configurations in the previous 
sections. The first of these was a direct relabeling equivalence an the second 
was the equivalence induced by a history relation. Neither of these equiv- 
alences is satisfactory. The history relation was shown to be too weak; it 
collapses too many configurations into the same equivalence class. 

The equivalence relation induced by direct relabeling is not satisfactory 
in an admittedly direct sense. For example, suppose two configurations were 
identical except that at one mail address m the actors in their respective 
states differed in that only the tags and mail addresses created by them 
were unequal. (This could happen using our definition of the behavior 
function if, for example, the order of new expressions was different). Using 
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direct equivalence, these configurations would not be mapped to the same 
equivalence class. What we would like to do is to consider configurations 
that have transitions to equivalent configurations equivalent. Fortunately 
an inductive definition, establishing equivalences to depth n for an arbitrary 
depth, is not necessary for this purpose: Since there are only a finite number 
of behavior definitions, their equivalence under relabeling can be directly 
established as well. 

Unfortunately, this weaker relabeling equivalence is not satisfactory ei- 
ther. Consider two configurations which are identical except that one of 
them has an actor x such that: 

1. x is not a receptionist; 

2. a; is not the target of any task in the configuration; and 

3. the mail address of x is not known to any other actor and is not in 
any of the communications pending in the configuration. 

It can be safely asserted that the two configurations, with and without the 
actor x, are equivalent (see §3.1.1). In implementation terms, the actor x 
would be a suitable candidate for garbage collection. However, these two 
configurations are clearly not equivalent under relabeling. 

We therefore need to define a notion of observation equivalence between 
configurations (following [Milner 80]). The only events "observable" in a 
encapsulated system are of two kinds: 

• Communications sent from the outside to some receptionist; and 
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• Communications sent by an actor in the population to an external 
actor. 

This suggests three kinds of transitions from each configuration — tran- 
sitions involving the acceptance of a communication sent from the outside 
to a receptionist (input), a transition involving the sending of a communi- 
cation to an external actor (output), and an internal action (corresponding 
to processing a task in the configuration which is internal to the config- 
uration). The first kind of transition leads to a configuration c' from a 
given configuration c such that tasks(c') = tasks(c)Ur where r is the task 
accepted from the outside. The other two kinds transitions are the ones 
already defined in chapter 5, except that we ignore the labels on all tran- 
sitions that are not targeted to an external actor. We can now identify 
computation in actor systems as a tree with these three kinds of labels on 
its branches (see Appendix). 

How does the composition of trees work in this framework? In CCS, 
when two trees are combined, the inputs and outputs are matched in a syn- 
chronous manner and constitute a silent transition. Rather surprisingly, no 
change in the technical aspect of this definition is necessary to accommo- 
date composition in actor systems despite the fact that communication is 
asynchronous in actor system. The reason is simply as follows: Only the ac- 
ceptance of a communication constitutes a transition from a configuration, 
thus when two configurations are composed all we are doing is reconciling 
the acceptance of a communication by an external actor, with the subse- 
quent behavior of that actor. The latter is given by the actions in the tree 
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corresponding to the configuration where the actor is a receptionist. Be- 
cause of arrival order nondeterminism, the arrival of the communication is 
delayed arbitrarily long in the first configuration, thus the composition is, 
in effect, asynchronous. 

A configuration can be extensionally defined using the tree of events 
specified above. The definition is inductive — two configurations are ob- 
servation equivalent to degree n if they have have the same observable 
transitions at the nik level of the tree. This notion differentiates between 
all the configurations one would want to differentiate between. After all, if 
it is impossible to observe the difference between two configurations despite 
any interaction one may have with the systems involved, then there is no 
point discriminating between the two systems. 

Brock [83] has proposed a model using scenarios which relate the inputs 
and the outputs of a system using a causal order between them. The model 
however has several limitations, such as fixed input and output "ports," and 
it does not support compositionality. The first of these two deficiencies is 
related to the lack of a labeling scheme such as is afforded by the mail 
address abstraction in actors. 

Philosophically, what we understand to be causality may be nothing 
more than necessary sequentiality: After all, the pragmatic significance of 
imputed causal inference in the physical world is simply an expectation of 
sequentiality in the spatio-temporal order between events considered to be 
the cause and those considered to be the effect. The inference of all causal 
relations is an open-ended, undecidable problem since the observation of a 
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cause may be separated from the observation of an effect by an arbitrary 
number of events. The same arbitrary delay property is true of the guar- 
antee of mail delivery. Both of these properties may only be deduced from 
a proposed model of the internal workings of a system rather than from 
observations on a system. In contradistinction, the notion of observation 
equivalence is based on the testability of equivalence to an arbitrary depth. 3 
The problem with the history relation is that it ignored the open, in- 
teractive nature of systems. Any system may accept a communication at 
any time, and given that it has produced a particular communication, its 
response to a subsequent input is different because of the transitions it has 
undergone to produce that particular communication. The communication 
produced is of course simply symptomatic of the change in the system. In- 
ternal!}', the change has already occurred, whether or not we have observed 
its external manifestation— i.e., whether or not the communication sent 
has been received. On the one hand, until we observe the effects of the 
change, there is uncertainty, from the external perspective, as to whether 
the change has already occurred. On the other hand, after we have ob- 
served the effects of a transition, we have at best a model for how the 
system was at the time the transition occurred rather than a model of its 



3 Admittedly, a curious proposition since we can test only one path of possible evolutions 
of a system. The usual solution to this difficulty is having an arbitrary number of 
systems pre-determined to be equivalent, presumably in some stronger physical sense. 
The idea is to experiment on these systems in different ways to determine their behavior 
to any desired degree. 
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"current" status. 4 However, if we have any understanding of the mechanics 
of a system, given a communication from that system, we can prune the 
tree of possible transitions that the system may have taken. 



4 Compare the reasoning behind the old Heisenberg Uncertainty Principle to the situation 
here. An interestinng discussion of "quantum physics and the computational metaphor" 
can be found in [Manthey and Morey 83]. 



Chapter 8 



Conclusions 



We have developed a foundational model of concurrency. The model uses 
very few primitive constructs but can nevertheless accommodate the re- 
quirements for a general model of concurrent computation in distributed 
systems. The flavor of transitions in actors is one of a pure calculus for 
concurrency; it differs from Milner's Calculus of Concurrent Systems pri- 
marily in two respects: it does not assume synchronous communication, 
and, it explicitly provides for dynamic creation of agents. 

Actors integrate useful features of functional programming and object- 
oriented programming. While other functional systems have some measure 
of difficulty dealing with history- sensitive shared objects, actors do so quite 
easily. At the same time, actors avoid sequential bottlenecks caused by 
assignments to a store. The concept of a store, in the context of parallel 
processing, has been the nemesis of the von-Neuman architectures. 

Actors are inherently parallel and exploit maximal conciirrency by using 
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the dynamic creation of customers and by pipelining the replacement pro- 
cess. The semantics of replacement is fundamentally different from changes 
to a local store. Replacements may exist concurrently. This kind of pipelin- 
ing can be a powerful tool in the exploitation of parallel processors. In fact 
pipelining (specifically, instruction pre- fetching), has been an extremely 
successful tool in speeding up the computation on many processors cur- 
rently in use. Unfortunately, the degree to which pipelining can be carried 
out in the current generation of processors is restricted by the ubiquitous 
assignments to a store, and the use of global states implicit in the pro- 
gram counter. Actors allow pipelining to be carried out to its logical limits 
as constrained by the structure of the computation and by the hardware 
resources available. 

Perhaps the most attractive feature about actors is that the programmer 
is liberated from explicitly coding details such as when and where to force 
parallelism and can concentrate on thinking about the parallel complexity 
of the algorithm used. If one is to exploit massive parallelism, using parallel 
processors on the order of tens, perhaps hundreds, of millions of processors, 
it will not be feasible to require the programmer to explicitly create every 
process which may be executed concurrently. It is our conjecture that 
actors will provide the most suitable means for exploiting parallelism made 
feasible by the advent of distributed systems based on VLSI. 

Message-passing is elemental to computation in actors. The time com- 
plexity of communication thus becomes the dominant factor in program 
execution. More time is likely to be spent on communication lags than 
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on the primitive transformation on the data. Architectural considerations 
such as load balancing, locality of reference, process migration, and so forth, 
acquire a pivotal role in the efficient implementation of actor languages. 

The information provided by a transitional model of actor systems is 
too detailed to be of "practical" use. The structure of transactions and 
transaction-based reasoning for the verification of actor programs needs to 
be studied. The semantics developed here will simply provide the justifi- 
cation for such axiomatic treatment. The open and interactive nature of 
actors implies that any description of actor behavior will necessarily in- 
volve a combinatorial explosion in the exact configurations possible in a 
system. However, by establishing invariants in the behavior of a actor, we 
can satisfy our self as to its correctness. The importance of proving pro- 
gram correctness in concurrent systems is underscored by the fact that it is 
not possible to adequately test such systems in practice. In particular, ar- 
rival order nondeterminism implies that any particular sequence of message 
delivery need never be repeated regardless of the number of tests carried 
out. 

Another critical problem for computer architectures to support actors 
is controlling compiitational activity. Since actors may be shared objects, 
one can not simply assign them a fixed amount of computational resources 
upon creation. If transactions involving the same actors are concurrently 
executed, the resources used by each transaction need to be assessed sepa- 
rately. Furthermore, concurrent sub- transactions are spawned dynamically 
in actor system as many messages may be sent in response to a single mes- 
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sage. These sub- transactions must be allocated resources dynamically as 
well. Since it is impossible to correctly assess the computational resources 
needed, the allocation has to be constantly monitored. The problem of 
transactions is in general intractable if the transactions are not properly 
nested. 

We have addressed a number of general problems that plague compu- 
tation in distributed systems. Among these problems are deadlock, diver- 
gence, abstraction and compositionality. The problem of deadlock is dealt 
with by the universal replacement requirement. The effects of divergence 
on the semantics of a computation are contained by the guarantee of mail 
delivery. The problem of abstraction is addressed by the concepts of recep- 
tionists and transactions and, at the model-theoretic level, by the notion 
of observation equivalence. And finally we support compositionality using 
pure message-passing. 

A simple minimal actor language is shown to be sufficient to accom- 
modate extremely expressive structures, including potentially infinite ones. 
The denotational semantics of actor behaviors is defined and a transition 
relation for configuration follows simply from the semantics. Finally, we 
have dealt with equivalence relations between actors and provided some 
connections with other models of concurrency. 



Appendix A 

Asynchronous Communication 
Trees 



Milner [80] has developed an elegant calculus for synchronously commu- 
nicating agents (called CCS). As an aid to visualizing computation in a 
system of such agents, Milner has proposed Communication Trees (CTs) 
as a model for CCS. As Milner has observed, CTs are actually more pow- 
erful than CCS; in other words, there are large classes of CTs which can 
not be expressed as programs in CCS. For example, the topology implied 
by CCS is static whereas there is no such restriction on CTs. We develop 
Asynchronous Communication Trees (T's) as a model to aid in visualizing 
computation in actors and a means by which we can define composition, 
direct equivalence, observation equivalence, etc., in actor systems. The in- 
triguing feature of T's is that they capture the open, interactive nature of 
computation in actors. It is recommended that the reader carefully study 
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Milner's work, in particular Chapters 5 and 6 before trying to figure out 

the material here in any depth. 

There are three fundamental differences between actors and CCS: 

• Communication is synchronous in CCS while it is asynchronous in 
actors. 

• The topology on CCS agents is static while communications in actors 
may contain mail addresses. 

• There is no dynamic creation of agents in CCS while actors may be 
created dynamically. 

Rather surprisingly, the algebra used to define T's is almost identical to 
that used in CTs; the primary difference is in the concrete interpretations 
associated with each. We interpret only the acceptance of a communication 
as a transition (what Milner calls "action"): Sending a communication is 
simply represented by the fact that every branch of the tree has a transition 
corresponding to the acceptance of the communication by its target. This 
fact follows from the guarantee of mail delivery. 

We represent each configuration as an T. A few simplifying assumptions 
will be made. First, we assume that there are no mail address conflicts be- 
tween different configurations (since we provide a relabeling operator, this 
is without loss of generality). Second, we assume that the external mail 
addresses represent the true mail address of the external actor. When two 
configurations are composed, this will be a useful simplification. The jus- 
tification for this assumption is two-fold: firstly, using message-passing the 
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external actor forwards all mail it has received to the actor it is supposed 
to become; and secondly, the communications it sent to the external ac- 
tor can arrive in any order in the first place. Thirdly, we assume that 
there are a countable number of communications, which may be enumer- 
ated as fco,fci, . . . • Any communication may be sent to any actor, if the 
communication sent is inappropriate (such as having the wrong number of 
"parameters"), then we assume there is a default behavior. We can assume 
that the tags of tasks are part of the enumeration of communications and 
used to create new mail addresses. 1 However, tagging tasks is not useful in 
defining observation equivalence; furthermore, it is also possible to specify 
a different mechanism to create mail addresses using other mail addresses. 
The technical development remains quite similar. 
A typical T consists looks like Fig A.l 




Figure A.l: A typical Asynchronous Communication Tree 
The three kinds of potential transitions (or in Milner's terminology, 



'Recall that a union of all finite collections of a countable set is still countable. 



APPENDIX A. ASYNCHRONOUS COMMUNICATION TREES 179 

actions) have the following intuition: 

(i) Corresponding to each current receptionist in the configuration is a 
potential transition labeled by its mail address (these are the positive 
labels, a, . . . , in the figure) and the communication it may accept. 
The Oh tree it dominates represents the behavior of the configuration 
if the receptionist accepts a communication k(. 

(ii) For all communications accepted by an external actor, there is a tran- 
sition to the tree corresponding to the behavior of a configuration 
without the pending communication. These transitions are labeled by 
the mail address of the external actor (using negative labels 57, . . . ,). 

(iii) For all communications accepted by an actor in the population, there 
is an internal transition (labeled by g). 2 

The relation between configurations and T's should be intuitively clear 
from the above description. If each node were marked by the configu- 
ration it represented, then (i) would correspond to a transition from a 
configuration c to a configuration c' such that states (c) = states (c') and 
tasks(c') = tasks(c) U r where r is the task accepted from the outside; 
(ii) is the acceptance of a communication by an external actor, and (iii) is 
acceptance of a communication by any actor in the population. 

When an actor accepts a communication, it may create other actors or 
send new communications to specific targets. These will simply show up 



2 Milner represents internal transitions, or what he terms "silent actions," by r but we 
used that letter to denote tasks. 
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in the stibsequent behavior of the configuration to which the transition is 
made. We do not label nodes in our trees (cf. Milner's CTs) because the 
label would be simply another way of noting the sub- tree dominated by the 
given node. Formally we define an ACT as follows: 

Definition A.l Asynchronous Communication Trees. Assume the 
function extern(k) represents the external actors communicated in k. An 
T with receptionists R and external actors E is a finite set 3 of pairs of the 
form 

(i) < a, f > a G R where f is a family of T 's with receptionists R and 
external actors E U extern(ki) indexed by possible communications ki 
accepted; or, 
(ii) < (3,< k,t » /? £ E tuhere k is a communication targeted to the 
mail address j3 and t is an T with receptionists R and external actors 
E U extern{k); or, 
(Hi) < q, t > where t is an T with receptionists R and external actors E. 

Remark. The receptionists denote all the current receptionists as well 
as the (potential) future receptionists; the external actors denote only the 
currently known external actors. The asymmetry arises because any fu- 
ture receptionists are created locally thus their potential mail addresses 
are internally determined (even if they are functions of the incoming tags), 



s We do not need a multiset because all mail addresses are unique. However, T's in their 
full generality may lack rules guaranteeing uniqueness of mail addresses. Technically 
this does not create any difficulty; it simply changes the nature of nondeterminism. 
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however the mail addresses of external actors which become known as a 
result of an incoming communication are in principle unknowable. 

We will now define an algebra of T's and then define three operations 
namely, composition, restriction, and relabeling on the T's. The actual 
algebra is almost identical to CTs except, not surprisingly, in the notion of 
receptionists and external actors. CTs used sorts which were a fixed set for 
each CT. The concrete interpretations placed on the terms are, of course, 
quite different. The definitions below are adapted from [Milner 80]. 

Let Tp x j£ denote the T's with receptionists R and external actors E 
and fco, ki, . . . , denote the possible communications. We have an algebra of 
T's as follows: 

NIL(nullary operation) 
NIL is the T • 

+ (binary operation) 

+ e r Ri x Ex x r R 2 xE 2 ~* T RxE 
where R - (RxU R 2 ) and E = {Ex U E 2 ) 

a (a u;-ary operation) 

a takes a set of members of T^ x £ indexed by &o, kx , . . . , and produces 

a member of T (flu ^ Q jj x ( E U extern^)) for the k ~ member - This 
operation adds a receptionist with mail address a, see Fig A. 3. Let K = 
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Figure A. 2: Possible nondeterministic transitions. 
{fc , fci,...}, then 

« e {< -> Tfl x #) -» T^ u ^ x ^ 

a (a family of unary operations) 

VA: 5(A) e r R x # -+ T fi x (jgy u ex tcrn(*)) 

a(fc) represents the fact that the communication k has been accepted by 
an external actor with the mail address a. See Fig A.4 

q (a unary operation) 

The interpretation of the + operation is nondeterminism in the model — 
ti + £2 simply means that we may be in the tree t\ or in the tree t%. The rest 
of the operations are straight-forward and correspond to their description in 
the introduction. The trees differ from the transitions model of Chapter 5 in 
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Figure A.3: A new receptionist definition. 



a(k) 





Figure A. 4: Acceptance of a communication by an external actor. 



that they represent computation in an open system: It is possible to send a 
communication from the outside to a receptionist (the potential transitions 
are included to account for this fact). However configurations contain all 
the information necessary to map them into the trees and, furthermore, we 
can commute the diagram of the composition maps in configurations and 
T's. 

The mechanics of how T's are built will become clearer with the com- 
position operation. Composition will allow us to combine acceptance of 
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communications sent to the receptionists (positive label bindings) in one 
tree with acceptance by the corresponding external actors (negative label 
bindings) in a different tree to create an internal action of the composite. 
We now provide three operations on T's, namely, (concurrent) composition, 
restriction and relabeling. 

Composition 

Composition, ||, is a binary operation on T's such that: 

II e T /2i x Ei x r R 2 x E 2 "* T R x E 

where R = (R k UR 2 ), E = (E 1 -R 2 ) U (E 2 - R k ) and (Jfc nR 2 ) = 0. Let 
(Gig x j^ and u G Tj^ x ^ , then t \\ u has the following branches: 

(i) For each branch of t representing a communication from the outside 
to a receptionist (i.e., for the branches with the positive labels), there 
is a branch which represents the input followed by the composition 
with u of each of the trees it dominates. This branch reflects the fact 
that communications may be received by receptionists in t before any 
other actions take place. Mutatis mutandis for the receptionist of u. 

(ii) For each branch of t representing an internal transition, a branch 
corresponding to the internal transition followed by the composition 
with u of the tree it dominates. This simply says that the internal 
action could happen before any of the effects of composition happen. 
Mutatis mutandis for branches of u. 



APPENDIX A. ASYNCHRONOUS COMMUNICATION TREES 185 

(iii) For each branch of t representing a communication to an external 
actor j3 there are two possibilities. If /3 $■ R% then there is simply a 
equivalent branch followed by the composition with u of the tree it 
dominates. Otherwise, for each branch of u representing a commu- 
nication from the outside to the receptionist /?, there is an internal 
action followed by the composition of the tree in u which follows ac- 
cepting the given communication and the tree the "output" branch 
dominates. The acceptance has been internalized because of the com- 
position. Mutatis mutandis for "output" branches of u. 

The composition operator preserves arrival order nondeterminism since 
it simply represents the interleaving of all the possibilities. 

Restriction 

The restriction operation, \, removes a receptionist from a system. The 
result is that the mail address removed is no longer available for composi- 
tion with other trees. However, if the corresponding actor was involved in 
accepting any communications from actors within the configuration, then 
these transitions are unaffected. One obviously can not remove internal 
actions since they are not "guarded" by the mail address. Formally, 

\ a e r RxE-+ T {R- {a}) x E 

Relabeling 

Given a map from mail addresses to mail addresses, this operator changes 
both the positive and negative bindings associated with each. It is unary 
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operator. Note that in an actor system, R D E — 0, therefore positive and 
negative versions of the same label can not co-exist in the same T. 

We skip the straight-forward recursive definitions of restriction and re- 
labeling. 

The algebra now behaves like the algebra of CTs; in particular, the same 
definitions of strong equivalence and observation equivalence can be used. 
Observation equivalence on T's provides an intuitively abstract description 
of actor systems and retains the right amount of information. We refer to 
[Milner 80] for details. 

An interesting, and not too difficult exercise, is to draw sufficient frag- 
ments of the T's for the two systems Sy and S 2 used in discussion of the 
Brock-Ackerman anomaly (§7.3). These T's are indeed not observation 
equivalent. 

One remark may be pertinent, if peripheral, here. Milner has shown 
that observation equivalence is a congruence relation for all operations ex- 
cept the "+" operator. The counter-example which shows that observation 
equivalence is not a congruence relation uses the absorption property of the 
NIL tree under the + operation. The counter-example would not work if 
NIL had internal transitions to NIL. In any case, a congruence relation can 
be defined in terms of observation equivalence. 
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